Restful --- 讓JSON迴歸單純

設計模式纔是軟件哲學的根本。。

 

一種軟件架構風格、設計風格，而不是標準，只是提供了一組設計原則和約束條件。它主要用於客戶端和服務器交互類的軟件。基於這個風格設計的軟件能夠更簡潔，更有層次，更易於實現緩存等機制。

 

http的api設計藝術一直是個爭論不休的命題， 話說，api接口本無標準，（確實沒有標準）可是正確的設計模式和行業規範可以大大的方便用戶和其餘開發者， 同時開發新項目的時候減小本身思考的時間。我之前也很討厭學習瞭解規範， 認爲它約束了咱們的代碼， 減小了自由度，可是在工做中你不得不遵循團隊的開發模式。就如同material design pattern同樣，雖然它給藝術強加了一個‘標準’，可是你們都很喜歡她。

Restful api，Representational State Transfer， 就是api領域的一個規範，也是由http2.0開發者提出的一種通用方法，自從使用這主公規範之後， 我發現開發小型網站的效率一會兒上去了。。。

請求方法的設計

http的經典作法是兩個傳遞方向：請求和迴應，請求的request有經典的method之選：

• GET：讀取（Read）
• POST：新建（Create）
• PUT：更新（Update）
• PATCH：更新（Update），一般是部分更新
• DELETE：刪除（Delete）

很遺憾的是， 絕大多數人都只用前兩個

這是個很悲劇的現象， 和http的創始人的構想相距甚遠， 確實，只用post或者get徹底能偶實現大多數應用， 可是幾乎全部的 請求服務都分爲增刪改查（CRUD），而method就是爲這個而設計的，若是不用method，你就得在url路徑中制定哪一種服務，好比：

• /getAllUsers
• /addNewUser
• /dropOneUser
• /setManyUsers

這簡直太醜陋了！！

RESTful 的核心思想就是，客戶端發出的數據操做指令都是"動詞 + 賓語"的結構。好比，GET /articles這個命令，GET是動詞，/articles是賓語。

因而可知，充分利用標準才能減小代碼量， 使得邏輯更通順，更可擴展

面向對象的思想

談完了request，在談談http body體的設計：

這裏主要是面向對象，即將body（json對象）中全部零碎的數據封裝成一個個對象，若是隻有一個對象就不須要引用名

設計公共API響應佈局的目的是平衡消費者的易用性和提供者的穩定性承諾。咱們能夠依賴各類瘋狂的元數據和嵌入式值，咱們會後悔多年後保留它們，好比複雜的分頁方案，這些方案不能擴展到不斷擴展的域空間，或者當咱們最終成爲Web Scale並浪費數百萬的額外帶寬時從那個表情符號湯咱們認爲包裝每一個條目將是熱鬧的。

這個思想和函數參數列表是相通的（多參數封裝對象， 單參數直接使用）

那些不適合CRUD的行爲呢？

假如一個操做既get又set，這種組合是事情變得模糊的地方，既屬於set也屬於get。有不少例子：

1. 將操做重組爲顯示爲資源字段。若是操做不採用參數，則此方法有效。例如，激活動做能夠映射到布爾激活的字段，並經過PATCH更新到資源。
2. 將其視爲具備RESTful原則的子資源。例如，GitHub的API讓你用PUT / gists /：id / star和unstar與DELETE / gists /：id / star打造一個要點。
3. 有時你真的沒法將動做映射到合理的RESTful結構。例如，多資源搜索實際上沒有意義應用於特定資源的端點。在這種狀況下，即便它不是資源，/ search也會最有意義。這不要緊 - 只需從API使用者的角度作正確的事情，並確保明確記錄以免混淆。

狀態代碼設計藝術

終於談到response了，http返回包最重要是狀態嗎，請求只有幾種，但返回結果有無數種可能，HTTP 狀態碼就是一個三位數，分紅五個類別。

• 1xx：相關信息
• 2xx：操做成功
• 3xx：重定向
• 4xx：客戶端錯誤
• 5xx：服務器錯誤

這五大類總共包含100多種狀態碼，覆蓋了絕大部分可能遇到的狀況。每一種狀態碼都有標準的（或者約定的）解釋，客戶端只需查看狀態碼，就能夠判斷出發生了什麼狀況，因此服務器應該返回儘量精確的狀態碼。

狀態碼對應請求的method，不少人有一個惡習就是狀態通通不考慮， 統統200，可是錯誤信息卸載json中，好比：

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "not ok",
    code:1
  "info": {
    "error": "Permission Denied !!"
  }
}

這種習慣是很是噁心的，好好的狀態代碼你不用，非要自定義，不是有病嗎？要知道，fetch獲得http第一個分組的時候就解析了response的promise，這時候就能夠經過http頭部的狀態碼來識別是否成功，若是非要自定協議就得等到http（流）徹底結束後才能知道是否發生了錯誤，這是很是低效率的作法，雖然response對象還在試驗階段，可是隨着投票人數的增多， 很快會成爲標準化，大膽地用吧！

騷操做

restful的大體藝術就是如上，可見REST和CRUD仍是很經典的概念，和unix定義的操做系統基本元素同樣，幾十年內是不會過期的，上米娜說到的規範固然不是所有， 咱們還能夠在api中添加一些彩蛋，充分利用上面講到的全部的http元素來實現本身的騷操做，好比api的wiki：

API 的使用者未必知道，URL 是怎麼設計的。一個解決方法就是，在迴應中，給出相關連接，便於下一步操做。這樣的話，用戶只要記住一個 URL，就能夠發現其餘的 URL。這種方法叫作 HATEOAS。

舉例來講，GitHub 的 API 都在 api.github.com 這個域名。訪問它，就能夠獲得其餘 URL。不信你能夠點擊試一試

關於restful風格和rpc風格的api設計和公司同事有過爭論，感受是主義之爭，不會有什麼結果。不過關於rest風格，在實際應用中，也遇到過難處理的問題，好比，client驗證用戶名或者電話是否存在，就不知如何設計怎麼好，最後「強行」設計成：GET /users/checking(validating)?username=xx，反卻是，rpc風格，GET /users.check?username=xx是否表達力更強一些。再如，某個操做致使狀態更新，總結下，就是對於有很強的「動做」在內的api，restful風格並不徹底適用，只是稍微有點麻煩。

綜上所述，合理的restful設計能夠知足平常生活中99%的需求，讓開發者感到‘ very restful’