restful是一種軟體架構風格、設計風格，而不是标準，隻是提供了一組設計原則和限制條件。它主要用于用戶端和伺服器互動類的軟體。基于這個風格設計的軟體可以更簡潔，更有層次，更易于實作緩存等機制。
對網絡上所有的資源都有一個資源标志符。
對資源的操作不會改變辨別符。
同一資源有多種表現形式（xml、json）
所有操作都是無狀态的（stateless）
1.1 動詞 + 賓語
restful 的核心思想就是，用戶端發出的資料操作指令都是"動詞 + 賓語"的結構。比如，<code>get /articles</code>這個指令，<code>get</code>是動詞，<code>/articles</code>是賓語。
動詞通常就是五種 http 方法，對應 crud 操作。根據 http 規範，動詞一律大寫。
get：讀取（read）（安全）
post：建立（create）（不幂等）
put：更新（update）
patch：更新（update），通常是部分更新
delete：删除（delete）
1.2 動詞的覆寫
有些用戶端隻能使用get和post這兩種方法。伺服器必須接受post模拟其他三個方法（put、patch、delete）。
這時，用戶端發出的<code>http</code>請求，要加上<code>x-http-method-override</code>屬性，告訴伺服器應該使用哪一個動詞，覆寫<code>post</code>方法。
上面代碼中，<code>x-http-method-override</code>指定本次請求的方法是<code>put</code>，而不是<code>post</code>。
1.3 賓語必須是名詞
賓語就是 api 的 url，是 http 動詞作用的對象。它應該是名詞，不能是動詞。比如，/articles這個 url 就是正确的，
而下面的 url 不是名詞，是以都是錯誤的。
1.4 複數 url
既然 url 是名詞，那麼應該使用複數，還是單數？
這沒有統一的規定，但是常見的操作是讀取一個集合，比如<code>get /articles</code>（讀取所有文章），這裡明顯應該是複數。
為了統一起見，建議都使用複數 url，比如<code>get /articles/2</code>要好于get /article/2。
1.5 避免多級 url
常見的情況是，資源需要多級分類，是以很容易寫出多級的 url，比如擷取某個作者的某一類文章。
這種 url 不利于擴充，語義也不明确，往往要想一會，才能明白含義。
更好的做法是，除了第一級，其他級别都用查詢字元串表達。
下面是另一個例子，查詢已釋出的文章。你可能會設計成下面的 url。
查詢字元串的寫法明顯更好。
2.1 狀态碼必須精确
用戶端的每一次請求，伺服器都必須給出回應。回應包括<code>http狀态碼</code>和<code>資料</code>兩部分。
http 狀态碼就是一個三位數，分成五個類别。
1xx：相關資訊
2xx：操作成功
3xx：重定向
4xx：用戶端錯誤
5xx：伺服器錯誤
這五大類總共包含100多種狀态碼，覆寫了絕大部分可能遇到的情況。每一種狀态碼都有标準的（或者約定的）解釋，用戶端隻需檢視狀态碼，就可以判斷出發生了什麼情況，是以伺服器應該傳回盡可能精确的狀态碼。
api 不需要1xx狀态碼，下面介紹其他四類狀态碼的精确含義。
2.2 2xx 狀态碼
<code>200</code>狀态碼表示操作成功，但是不同的方法可以傳回更精确的狀态碼。
get: 200 ok
post: 201 created
put: 200 ok
patch: 200 ok
delete: 204 no content
上面代碼中，post傳回<code>201</code>狀态碼，表示<code>生成了新的資源</code>；<code>delete</code>傳回<code>204</code>狀态碼，表示<code>資源已經不存在</code>。
此外，<code>202 accepted</code>狀态碼表示伺服器已經收到請求，但還未進行處理，會在未來再處理，通常用于異步操作。下面是一個例子。
2.3 3xx 狀态碼
api 用不到<code>301</code>狀态碼（永久重定向）和<code>302</code>狀态碼（暫時重定向，307也是這個含義），因為它們可以由應用級别傳回，浏覽器會直接跳轉，api 級别可以不考慮這兩種情況。
api 用到的3xx狀态碼，主要是<code>303 see other</code>，表示參考另一個 url。它與302和307的含義一樣，也是"暫時重定向"，差別在于302和307用于get請求，而303用于post、put和delete請求。收到303以後，浏覽器不會自動跳轉，而會讓使用者自己決定下一步怎麼辦。下面是一個例子。
2.4 4xx 狀态碼
<code>4xx</code>狀态碼表示用戶端錯誤，主要有下面幾種。
400 bad request：伺服器不了解用戶端的請求，未做任何處理。
401 unauthorized：使用者未提供身份驗證憑據，或者沒有通過身份驗證。
403 forbidden：使用者通過了身份驗證，但是不具有通路資源所需的權限。
404 not found：所請求的資源不存在，或不可用。
405 method not allowed：使用者已經通過身份驗證，但是所用的 http 方法不在他的權限之内。
410 gone：所請求的資源已從這個位址轉移，不再可用。
415 unsupported media type：用戶端要求的傳回格式不支援。比如，api 隻能傳回 json 格式，但是用戶端要求傳回 xml 格式。
422 unprocessable entity ：用戶端上傳的附件無法處理，導緻請求失敗。
429 too many requests：用戶端的請求次數超過限額。
2.5 5xx 狀态碼
5xx狀态碼表示服務端錯誤。一般來說，api 不會向使用者透露伺服器的詳細資訊，是以隻要兩個狀态碼就夠了。
500 internal server error：用戶端請求有效，伺服器處理時發生了意外。
503 service unavailable：伺服器無法處理請求，一般用于網站維護狀态。
3.1 不要傳回純本文
api 傳回的資料格式，不應該是純文字，而應該是一個<code>json</code>對象，因為這樣才能傳回标準的結構化資料。是以，伺服器回應的<code>http</code>頭的<code>content-type</code>屬性要設為<code>application/json</code>。
用戶端請求時，也要明确告訴伺服器，可以接受<code>json</code>格式，即請求的<code>http</code>頭的<code>accept</code>屬性也要設成<code>application/json</code>。下面是一個例子。
3.2 發生錯誤時，不要傳回 200 狀态碼
有一種不恰當的做法是，即使發生錯誤，也傳回200狀态碼，把錯誤資訊放在資料體裡面，就像下面這樣。
上面代碼中，解析資料體以後，才能得知操作失敗。
這張做法實際上取消了狀态碼，這是完全不可取的。正确的做法是，狀态碼反映發生的錯誤，具體的錯誤資訊放在資料體裡面傳回。下面是一個例子。
在一次請求中，content body僅僅用于傳輸資料。header中存放描述請求或請求的中繼資料
3.3 提供連結
api 的使用者未必知道，url 是怎麼設計的。一個解決方法就是，在回應中，給出相關連結，便于下一步操作。這樣的話，使用者隻要記住一個 url，就可以發現其他的 url。這種方法叫做<code>hateoas</code>。
舉例來說，github 的 api 都在 api.github.com 這個域名。通路它，就可以得到其他 url。
上面的回應中，挑一個 url 通路，又可以得到别的 url。對于使用者來說，不需要記住 url 設計，隻要從 api.github.com 一步步查找就可以了。
<code>hateoas</code>的格式沒有統一規定，上面例子中，github 将它們與其他屬性放在一起。更好的做法應該是，将相關連結與其他屬性分開。
阮一峰的網絡日志