先說REST名稱
REST -- REpresentational State Transfer
首先，之所以晦澀是因爲前面主語被去掉了，全稱是 Resource Representational State Transfer：通俗來講就是：資源在網絡中以某種表現形式進行狀態轉移。分解開來：
Resource：資源，即數據（前面說過網絡的核心）。比如 newsfeed，friends等；
Representational：某種表現形式，比如用JSON，XML，JPEG等；
State Transfer：狀態變化。通過HTTP動詞實現。
REST是什麼呢？ 它是一種架構風格，建立API時要遵守的一種規則/風格。REST 風格最早由 Roy Thomas Fielding 博士提出， REST 是一種系統架構設計風格，主要面向基於網絡的軟件架構設計。
在 REST 提出多年來，當前對於 REST 風格的應用最多的即是 Restful API 。
Restful API 一般分爲對外和對內。對外的 Restful API 爲面向公網的公共服務接口，此類接口一般可以通過公網直接訪問，或是經過一定的安全認證後通過公網訪問。而對內的 Restful API 則主要是一整套系統內部各個子系統或模塊之間交互的標準接口，相對於對外的 Restful API 接口，內部 API 接口更加標準化。
關於RESTful架構 可以看阮一峯的博客，寫的非常好。
理解RESTful架構 https://www.ruanyifeng.com/blog/2011/09/restful.html
現着重說下RESTful API 實戰應用。
一、URL 設計
1.1 動詞 + 賓語
RESTful 的核心思想就是，客戶端發出的數據操作指令都是"動詞 + 賓語"的結構。比如，GET /articles這個命令，GET是動詞，/articles是賓語。
動詞通常就是五種 HTTP 方法，對應 CRUD 操作。
- GET：讀取（Read）
- POST：新建（Create）
- PUT：更新（Update）
- PATCH：更新（Update），通常是部分更新
- DELETE：刪除（Delete）
根據 HTTP 規範，動詞一律大寫。
1.2 動詞的覆蓋
有些客戶端只能使用GET和POST這兩種方法。服務器必須接受POST模擬其他三個方法（PUT、PATCH、DELETE）。
這時，客戶端發出的 HTTP 請求，要加上X-HTTP-Method-Override屬性，告訴服務器應該使用哪一個動詞，覆蓋POST方法。
POST /api/Person/4 HTTP/1.1 X-HTTP-Method-Override: PUT
上面代碼中，X-HTTP-Method-Override指定本次請求的方法是PUT，而不是POST。
1.3 賓語必須是名詞
賓語就是 API 的 URL，是 HTTP 動詞作用的對象。它應該是名詞，不能是動詞。
1.4 複數 URL
URL 是名詞，那麼應該使用複數，還是單數？沒有統一的規定，
爲了統一起見，建議都使用複數 URL，比如GET /articles/5要好於GET /article/5。
1.5 避免多級 URL
常見的情況是，資源需要多級分類，因此很容易寫出多級的 URL，比如獲取某個作者的某一類文章。
GET /authors/12/categories/2
這種 URL 不利於擴展，語義也不明確，往往要想一會，才能明白含義。
更好的做法是，除了第一級，其他級別都用查詢字符串表達。
GET /authors/12?categories=2
二、狀態碼
2.1 狀態碼必須精確
客戶端的每一次請求，服務器都必須給出迴應。迴應包括 HTTP 狀態碼和數據兩部分。
HTTP 狀態碼就是一個三位數，分成五個類別。
1xx：相關信息2xx：操作成功3xx：重定向4xx：客戶端錯誤5xx：服務器錯誤
這五大類總共包含100多種狀態碼，覆蓋了絕大部分可能遇到的情況。每一種狀態碼都有標準的（或者約定的）解釋，客戶端只需查看狀態碼，就可以判斷出發生了什麼情況，所以服務器應該返回儘可能精確的狀態碼。
API 不需要1xx狀態碼，下面介紹其他四類狀態碼的精確含義。
2.2 2xx 狀態碼
200狀態碼錶示操作成功，但是不同的方法可以返回更精確的狀態碼。
- GET: 200 OK
- POST: 201 Created
- PUT: 200 OK
- PATCH: 200 OK
- DELETE: 204 No Content
上面代碼中，POST返回201狀態碼，表示生成了新的資源；DELETE返回204狀態碼，表示資源已經不存在。
此外，202 Accepted狀態碼錶示服務器已經收到請求，但還未進行處理，會在未來再處理，通常用於異步操作。下面是一個例子。
HTTP/1.1 202 Accepted { "task": { "href": "/api/company/job-management/jobs/2130040", "id": "2130040" } }
2.3 3xx 狀態碼
API 用不到301狀態碼（永久重定向）和302狀態碼（暫時重定向，307也是這個含義），因爲它們可以由應用級別返回，瀏覽器會直接跳轉，API 級別可以不考慮這兩種情況。
API 用到的3xx狀態碼，主要是303 See Other，表示參考另一個 URL。它與302和307的含義一樣，也是"暫時重定向"，區別在於302和307用於GET請求，而303用於POST、PUT和DELETE請求。收到303以後，瀏覽器不會自動跳轉，而會讓用戶自己決定下一步怎麼辦。下面是一個例子。
HTTP/1.1 303 See Other Location: /api/orders/12345
2.4 4xx 狀態碼
4xx狀態碼錶示客戶端錯誤，主要有下面幾種。
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 返回的數據格式，不應該是純文本，而應該是一個 JSON 對象，因爲這樣才能返回標準的結構化數據。所以，服務器迴應的 HTTP 頭的Content-Type屬性要設爲application/json。
客戶端請求時，也要明確告訴服務器，可以接受 JSON 格式，即請求的 HTTP 頭的ACCEPT屬性也要設成application/json。下面是一個例子。
GET /orders/2 HTTP/1.1 Accept: application/json
3.2 發生錯誤時，不要返回 200 狀態碼
有一種不恰當的做法是，即使發生錯誤，也返回200狀態碼，把錯誤信息放在數據體裏面，就像下面這樣。
HTTP/1.1 200 OK Content-Type: application/json { "status": "failure", "data": { "error": "Expected at least two items in list." } }
上面代碼中，解析數據體以後，才能得知操作失敗。
這張做法實際上取消了狀態碼，這是完全不可取的。正確的做法是，狀態碼反映發生的錯誤，具體的錯誤信息放在數據體裏面返回。下面是一個例子。
HTTP/1.1 400 Bad Request Content-Type: application/json { "error": "Invalid payoad.", "detail": { "surname": "This field is required." } }
一點小爭議
場景獲取用戶聊天信息 ： GET /messages?user=1
如果該用戶沒有聊天記錄，那返回數據時應該返回200的空值還是404不存在？
首先，restful風格的api的uri就是代表資源 ，採用動詞 + 賓語 ，
動詞代表GET（獲取）/POST（新增）/PUT（全量修改）/DELETE（刪除）/PATCH（部分修改）等等，
賓語就是資源。比如：POST /usrs ：代表新增一個用戶 ，GET /users:獲取所有用戶
而狀態碼即代表我們動賓後結果的狀態。
404在restful中代表：所請求的資源不存在，或不可用。
那麼我們的rest的api結果爲null返回404理論上沒有問題
但是目前很多用戶對404的理解不夠深，一看到404就覺得有問題，所以後端人員表示很無奈，
出於對用戶使用的友好，不得不在後端把404改成200，或者前端去特殊處理一下404。
一句話總結----404是政治正確，但200是目前更容易被接受