選擇一個 HTTP 狀態碼再也不是一件難事 – Racksburg《轉載》

本文轉載自：衆成翻譯 譯者：十年蹤影 連接：http://www.zcfy.cc/article/904 原文：http://racksburg.com/choosing-an-http-status-code/

有什麼能比 HTTP 響應狀態碼更簡單呢？頁面渲染了嗎？好極了，返回 200。頁面不存在？那麼是 404。想要跳轉到另外一個頁面？302 或者多是 301。

我喜歡把 HTTP 狀態碼想象成無線電波傳輸的 10 碼¹。「呼叫，呼叫，我是 White Chocolate Thunder，發現 200 OK。」

—— Aaron Patterson (@tenderlove) 2015-10-7

<!–more–>

生活是美好的……直到有人告訴你，你尚未作這個 REST²。而後你該失眠了，由於你需瞭解是否你的新資源返回符合 RFC 規範³，Roy-Fielding 規定的狀態碼。這裏只有 200 嗎？或者爲何沒有 204 No Content？或許有 202 Accepted……或者有 201 Created？

使事情複雜化的是，官方的 HTTP/1.1 指南 —— RFC —— 是寫於 1997 年的。† 在那一年，人們還在使用 Netscape 瀏覽器以 33.6 KB 的調制解調器來上網。在如今用 HTTP/1.1 就有點像把孫子兵法運用於現代企業戰略，兵法無疑是偉大的，但我根本不知道如何具體運用。

能不能有一種直觀的決策樹來讓你快速肯定你要用到的少數狀態碼，並將那些不相關的和廢棄的狀態碼排除掉？

固然能夠，如今就能給你一個。

從何提及

它可能看起來很好笑，可是我曾經看到過太多人分不清這些，「這裏應該用 503 Service Unavaliable 仍是 404 Not Found？」若是你曾經在這上面猶豫，那麼你徹底弄混了不一樣的響應類型，你的作法徹底是錯的。你應該回頭看看上面這張流程圖。

在深刻到具體規範的流程圖以前，有一些注意事項：

• 我建議你閱讀 RFC 7231 和 httpstatuses.com
• 如下內容對開發網站和設計 RESTish API 有用。
  • 狀態碼對具體的 web server 實現是徹底透明的
  • 固然這裏徹底忽略代理服務器
• 我將響應狀態碼粗略地歸爲三類：

最後但一樣重要的，免責聲明：我不保證我寫的徹底正確，我只是讀了一些 RFC 文檔在 Racksurg 公司實際工做時，天天用它來實現有用的 API。若是你認爲我是錯的或者我輕視了你最喜歡的狀態碼，那多是個人失誤，你能夠經過評論告知我究竟錯在哪裏。

2XX/3XX

4XX

5XX

結語：究竟爲何狀態碼重要

我並不徹底肯定它們真的重要。

Facebook 上有許多聰明人，他們建立了 API 只返回 200。

反對挑選指定狀態碼的基本觀點是：現有的狀態碼對於現代網站/API來講太通用了。它沒法讓客戶端以任何一種有意義的方式處理包含特定應用格式的細節的返回信息 —— 例如表單的哪個字段校驗失敗了以及爲何失敗了。既然如此，那麼爲何要在多餘的沒什麼用的 HTTP 狀態碼上浪費時間？

若是要給出一個理由，來講明爲何使用特定的狀態碼很重要，公認的理由是 HTTP 是一個分層的系統，若是響應狀態碼是有特定含義的，任何代理、緩存或者位於客戶端和服務器之間的 HTTP 框架可以更好地工做。我不認爲這個理由足夠更使人信服，尤爲如今每一個人都開始將服務遷移到 HTTPS，咱們禁止了任何不被服務器直接控制的代理或緩存節點。

然而，我會給你三個理由爲何我認爲狀態碼仍然很重要：

1. 客戶端已經處理（或者能夠方便地被擴展以便處理）具備特定行爲的不一樣狀態碼：

   • 相比於 302 Found，301 Moved Permanently 在 Google 等搜索引擎上有更好的 SEO 效果。
   • 301 Moved Permanently 可以被緩存，而 429 Too Many Requests 不被緩存等等。 有的客戶端庫能夠處理 429 Too Many Request，將請求回退並一天以後再次嘗試請求。 有的客戶端能夠用一樣的方式處理 503 Service Unavilable。

2. 即便對現代需求不能徹底知足，許多狀態碼依然表明着值得處理的特定響應（所以爲何不直接使用標準狀態碼？）。

   • 那些本該返回 405 Method Not Allowed 卻返回 404 的 API 讓我瘋狂地想，「究竟我是敲錯了 URL 仍是用錯誤的 HTTP method 請求了服務？」
   • 我能告訴你若是咱們返回 502 Bad Gateway（上游服務問題）而不是返回讓人困惑的 500 Internal Server Error，那麼咱們曾經能節省許多調試問題的時間。

3. 無論你信不信，反正我是信了，在普遍被使用的 API 中正在創建一個約定，以返回狀態碼例如 201 Created，429 Too Many Requests 以及 503 Service Unavialable。若是你遵循這個約定，用戶將能更方便地使用你的網站/API而且解決任何他們可能遇到的問題。

在這裏面，決定何時返回何種狀態碼是最難的，然而有了正確的知識（別再說我不知道，仔細看前面的流程圖），挑選一個有意義的狀態碼變得簡單不少。

說明

別去研究 RFC 2616，更別去研究 RFC 2068，真正有用的是 RFC 7231。

參考資料

• HTTP status code reference

• HTTP status codes used by world-famous APIs

• HTTP status codes visualized as a subway map

• Status Codes To Cat Memes As a Service

• Status Codes To Dog Memes As a Service

• 注¹：10碼，又稱十個信號，用來表示經常使用的短語，在語音通訊，特別是執法和公民波段（CB）無線電傳輸碼字。
• 注²：表述性狀態轉移：REST
• 注³：Request For Comments（RFC），是一系列以編號排定的文件。文件收集了有關互聯網相關信息，以及UNIX和互聯網社區的軟件文件。目前RFC文件是由Internet Society（ISOC）贊助發行。基本的互聯網通訊協議都有在RFC文件內詳細說明。RFC文件還額外加入許多的論題在標準內，例如對於互聯網新開發的協議及發展中全部的記錄。所以幾乎全部的互聯網標準都有收錄在RFC文件之中。