緣起

事情是這樣的，我在知乎受到邀請回答一個問題，主要是問 ID 找不到到底要不要用 Status 404 。我回答的還是比較早的，那時候只有一兩個回答。我本來以為這是沒啥爭議的，在一個學術的地方討論學術問題，當然是要遵守規(guī)范了，結果過了幾個小時大跌眼鏡。自造 code 黨竟然支持率第一，還好平時見的也很多的全 200 黨沒有受到支持，不然真的吐血了。

為什么要遵守規(guī)范

一般那種說特殊情況特殊處理，不要拘泥于規(guī)范的人，大多都是自己沒搞清楚某些知識，拿這句話當作偷懶的借口。其實一般做項目沒那么多特殊情況。

為了更好的適應各種庫

大部分完善的 HTTP 請求庫，都會依照 RFC 的規(guī)范去設計錯誤處理的流程，雖然處理方式各有不同，但一定會在文檔說明錯誤處理的部分的。使用 RFC 標準能最大限度的兼容各種 HTTP 客戶端。你說現(xiàn)在你用的HTTP客戶端不處理 Status Code，但是你沒法保證將來不重構，重構的時候還是不處理。

一般調用 api 使用 js 或者 python 的概率比較大，我們看看知名的庫。在 js 里，最近比較流行的 axios 默認會把 200 系列外的 code 歸到異常里。在 python 里，最流行的 http client 是 requests ，它更為詳盡的預處理了 status code 。

為了開發(fā)者更好上手

另外在管理團隊的方面，我們的原則是盡量的減少一個項目的“規(guī)范”，這樣才能更容易去遵守。能用標準的地方，一定不要自己定一個更復雜的規(guī)則。無論是服務端的維護者還是 API 的消費者是會換人流動的，每個進入項目的人熟悉一大堆無謂的自定義項目規(guī)范都要成本。

更簡單的辦法是參考大廠

其實給項目定規(guī)范，最不靠譜的是自己拍腦袋，稍好一點的是去知乎或論壇問，更好一點的是去 google 搜，最簡單的是直接去看大廠的產(chǎn)品或者規(guī)范啊。 API 本來就是個公開暴露的東西，還有比這更好找參考的嗎？我們來看看：

• Google 遵守規(guī)范
• Github 遵守規(guī)范
• Microsoft 遵守規(guī)范 順便說一句，微軟的 API 規(guī)范真的很具有指導意義。
• Twitter 遵守規(guī)范
• 阿里云 遵守規(guī)范
• 騰訊云 不遵守規(guī)范 全部 200 事實上騰訊的技術比較混亂，每個項目都不一樣。但最新要執(zhí)行的統(tǒng)一規(guī)范是全部 返回 200 用返回值中的錯誤碼表明錯誤。
• 百度云 遵守規(guī)范

我的建議

很多人也許用著很簡陋的 Web 框架，導致誤以為返回了錯誤碼，就不能返回 Response Body 了。其實你返回 204 外的任何 Status Code，最好都伴隨著返回 Body 。

在項目規(guī)范里，可以規(guī)定 Status Code 遵照 RFC 標準，或者選定一個集合出來，把一些不常用的去掉。然后如果不是200系列的代碼，必須伴隨著這樣的一個錯誤結構：

{"error": "UserNotFound","message": "該用戶沒有找到"}

這樣錯誤分為了三層結構，第一層是 Status Code，使用者能大概知道是什么問題。第二層Error 是一個 Key 使用約定好的無空格的英文，給使用者做判斷用，使用者可以根據(jù) Key 自定義接下來的操作。第三層是 message ，有些 Key 使用者可以決定直接把 Message 顯示個終端客戶。

如果是微服務項目，需要要求每個服務不管用什么語言，都要把錯誤統(tǒng)一成這個樣子。如果開發(fā)者告訴你框架不支持，那這一定不是個好框架，改重構了。好的框架不僅能讓你自定義錯誤內容，還能做到所謂的“框架自己出錯的返回”也由你自定義。比如路由沒有找到之類的。

最后

我實在不明白為什么一個最扯淡的答案，要自造一個 600 的 status code ，可以得票第一。知乎用戶到底有沒有一點獨立的判斷精神啊，只要裝的一本正經(jīng)，再擺出來一點資歷，哪怕是胡說八道，大家也紛紛點贊。也許真的不適合在知乎去回答技術問題了。

《新程序員》：云原生和全面數(shù)字化實踐50位技術專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的RESTful API 中的 Status code 是否要遵守规范的全部內容，希望文章能夠幫你解決所遇到的問題。

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