在設計API HTTP 狀態碼的時候，我們總能聽到兩種聲音：
第一種，也是大家最常用的：

所有接口的狀態碼都返回 200，然后在自定義錯誤碼：

# 正確響應 {"code: 200,"message": "success","data": {"id": ...,...} } # 錯誤響應 {"code: 1001, // 自定義錯誤類型"message": "error message","data": {} }

另一種，Rest API,僅使用HTTP狀態代碼：

# 正確響應 HTTP/1.1 200 Content-Type: application/json {"id": ...,... }# 錯誤響應 HTTP/1.1 401 Unauthorized {"message": "Bad credentials" }

更多的錯誤碼規范可以直接從 HTTP Status Code 查看。

為什么說是兩種聲音，其實現在基本規范的話都會直接選擇第二種，基本上，Github的

Github API v3以及現在普遍后端框架的設計都對于Rest API 有著更好的支持。
所以上面聲音的爭執似乎存在與前后端的更多些。

補充一下 Github v4 版本已經開始使用GraphQL了，GraphQL 是一種查詢語言，相比于Rest API的設計，現在國外比較喜歡和流行GraphQL ，但好像國內還并未聽說有過多的使用。

說一下兩者的優缺點吧，
第一種：

• 優點：客戶端僅需要處理作為 json字符串的響應主體并忽略狀態。
• 缺點：標準化低。

第二種：

• 優點：標準化高，客戶端僅需要處理作為json字符串的響應主體并忽略狀態。
• 缺點：業務復雜度高時的使用場景使用不足。

而結合兩種優缺點，現在許多人開始有了第三種方式：
HTTP Status 與Json body 相結合

• 優點：依舊能保證標準化，可以處理兼容更多的業務場景。
• 缺點：客戶端處理的復雜度高，需要根據業務場景做更多的判斷選擇

參考資料

Github API v3
HTTP Status Code
dingo-api 錯誤響應
Github v4

總結

以上是生活随笔為你收集整理的趣说API HTTP 状态码的使用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。