RESTFul API 基于 REST 的 API 設(shè)計理論：
- 輕
- 通常來說，使用 JSON 描述數(shù)據(jù)
- 無狀態(tài)（第二個請求不需要依賴第一個請求）
REST 提倡基于資源，增刪改查都是對于資源狀態(tài)的改變。
表示資源的方式是通過 url，所以 url 都提倡為名詞。
通過 http 動詞來描述資源的增刪改查，例如：GET、POST、PUT、DELETE。
設(shè)計：
錯誤示例：
/getmovie/:mid
正確示例：
GET: /movie/:mid
RESTFul API 實踐：
- http 動詞：
POST：創(chuàng)建
PUT：更新
GET：查詢
DELETE：刪除 - 明確意義的狀態(tài)碼：
常用：
404 - 資源沒有找到
400 - 參數(shù)校驗錯誤
200 - 查詢操作 GET 請求執(zhí)行成功
201 - 創(chuàng)建操作 POST 請求執(zhí)行成功
202 - 更新操作 PUT 請求執(zhí)行成功
401 - 未授權(quán)、沒有權(quán)限訪問該接口
403 - 有權(quán)限，但由于特殊原因，不允許訪問（防止A用戶傳B用戶id來操作B用戶的數(shù)據(jù)）
500 - 服務(wù)器的未知錯誤，1.未知的 bug。2.我知道是哪里的 bug，但這是我的服務(wù)器的原因，并不想讓客戶端知道。 - 錯誤碼：
自定義的錯誤ID號 - 統(tǒng)一描述錯誤：
錯誤碼、錯誤信息、當前URL - 使用 Token 令牌來授權(quán)和驗證身份。
- 版本控制
- 測試與生產(chǎn)環(huán)境分開
api.xxx.com
dev.api.xxx.com - 最好有一份比較標準的文檔
RESTFull API 異常分類：
- 由于客戶端行為導致的異常（沒有通過驗證器，沒有查到結(jié)果）
通常不需要記錄日志，需要向客戶端返回具體的信息 - 服務(wù)器自身異常（代碼錯誤，調(diào)用外部接口錯誤）
通常記錄日志，不向客戶端返回具體原因
以上只是通常情況，具體情況具體分析。比如說有個客戶端 ip 頻繁的抓取數(shù)據(jù)，這時候也可以記錄日志進行觀察。
