RESTful API 中的 Status code 是否要遵守規範
緣起
事情是這樣的，我在知乎受到邀請回答一個問題 ，主要是問 ID 找不到到底要不要用 Status 404 。我回答的還是比較早的，那時候只有一兩個回答。我本來以為這是沒啥爭議的，在一個學術的地方討論學術問題，當然是要遵守規範了，結果過了幾個小時大跌眼鏡。自造 code 黨竟然支援率第一，還好平時見的也很多的全 200 黨沒有受到支援，不然真的吐血了。
為什麼要遵守規範
一般那種說特殊情況特殊處理，不要拘泥於規範的人，大多都是自己沒搞清楚某些知識，拿這句話當作偷懶的藉口。其實一般做專案沒那麼多特殊情況。
為了更好的適應各種庫
大部分完善的 HTTP 請求庫，都會依照 RFC 的規範去設計錯誤處理的流程，雖然處理方式各有不同，但一定會在文件說明錯誤處理的部分的。使用 RFC 標準能最大限度的相容各種 HTTP 客戶端。你說現在你用的HTTP客戶端不處理 Status Code，但是你沒法保證將來不重構，重構的時候還是不處理。
一般呼叫 api 使用 js 或者 python 的概率比較大，我們看看知名的庫。在 js 裡，最近比較流行的 axios 預設會把 200 系列外的 code 歸到異常裡。在 python 裡，最流行的 http client 是 requests ，它更為詳盡的預處理了 status code 。
為了開發者更好上手
另外在管理團隊的方面，我們的原則是儘量的減少一個專案的“規範”，這樣才能更容易去遵守。能用標準的地方，一定不要自己定一個更復雜的規則。無論是服務端的維護者還是 API 的消費者是會換人流動的，每個進入專案的人熟悉一大堆無謂的自定義專案規範都要成本。
更簡單的辦法是參考大廠
其實給專案定規範，最不靠譜的是自己拍腦袋，稍好一點的是去知乎或論壇問，更好一點的是去 google 搜，最簡單的是直接去看大廠的產品或者規範啊。 API 本來就是個公開暴露的東西，還有比這更好找參考的嗎？我們來看看：
- Google 遵守規範
- Github 遵守規範
- Microsoft 遵守規範 順便說一句，微軟的 API 規範真的很具有指導意義。
- Twitter 遵守規範
- 阿里雲 遵守規範
- 騰訊雲 不遵守規範 全部 200 事實上騰訊的技術比較混亂，每個專案都不一樣。但最新要執行的統一規範是全部 返回 200 用返回值中的錯誤碼錶明錯誤。
- 百度雲 遵守規範
我的建議
很多人也許用著很簡陋的 Web 框架，導致誤以為返回了錯誤碼，就不能返回 Response Body 了。其實你返回 204 外的任何 Status Code，最好都伴隨著返回 Body 。
在專案規範裡，可以規定 Status Code 遵照 RFC 標準，或者選定一個集合出來，把一些不常用的去掉。然後如果不是200系列的程式碼，必須伴隨著這樣的一個錯誤結構：
{
"error": "UserNotFound",
"message": "該使用者沒有找到"
}
這樣錯誤分為了三層結構，第一層是 Status Code，使用者能大概知道是什麼問題。第二層Error 是一個 Key 使用約定好的無空格的英文，給使用者做判斷用，使用者可以根據 Key 自定義接下來的操作。第三層是 message ，有些 Key 使用者可以決定直接把 Message 顯示個終端客戶。
如果是微服務專案，需要要求每個服務不管用什麼語言，都要把錯誤統一成這個樣子。如果開發者告訴你框架不支援，那這一定不是個好框架，改重構了。好的框架不僅能讓你自定義錯誤內容，還能做到所謂的“框架自己出錯的返回”也由你自定義。比如路由沒有找到之類的。
最後
我實在不明白為什麼一個最扯淡的答案，要自造一個600
的 status code ，可以得票第一。知乎使用者到底有沒有一點獨立的判斷精神啊，只要裝的一本正經，再擺出來一點資歷，哪怕是胡說八道，大家也紛紛點贊。也許真的不適合在知乎去回答技術問題了。