REST API服務爲驗證失敗返回的適當HTTP狀態代碼是什麼？

每當我在基於Django / Piston的REST API應用程序中遇到驗證失敗時，我目前正在返回401 Unauthorized。 看過HTTP狀態代碼註冊表後我不相信這是驗證失敗的合適代碼，大家都推薦什麼？

• 400錯誤請求
• 401未經受權
• 403禁止
• 405方法不容許
• 406不可接受
• 412前提條件失敗
• 417指望失敗
• 422不可處理的實體
• 424依賴失敗

更新 ：上面的「驗證失敗」表示應用程序級別數據驗證失敗，即錯誤指定日期時間，虛假電子郵件地址等。

---

#1樓

RFC 2616中有關於這些錯誤語義的更多信息，它們記錄了HTTP 1.1。

就我的而言，我可能會使用400 Bad Request ，但這只是個人我的意見而沒有任何事實支持。

---

#2樓

「驗證失敗」到底是什麼意思？ 你在驗證什麼？ 你指的是語法錯誤（例如格式錯誤的XML）嗎？

若是是這種狀況，我會說400 Bad Request多是正確的，但不知道它是什麼「你正在驗證」，這是不可能的。

---

#3樓

我會說在技術上它可能不是HTTP失敗，由於資源（可能）有效地指定，用戶通過身份驗證，而且沒有操做失敗（可是，即便規範也包含一些保留代碼，如402 Payment Required are aren'嚴格來講，與HTTP相關，但建議在協議級別使用，以便任何設備均可以識別這種狀況。

若是確實如此，我會在響應中添加一個狀態字段，其中包含應用程序錯誤，例如

<status> <code> 4 </ code> <message>日期範圍無效</ message> </ status>

---

#4樓

若是「驗證失敗」意味着請求中存在某些客戶端錯誤，則使用HTTP 400（錯誤請求）。 例如，若是URI應該具備ISO-8601日期而且您發現它的格式錯誤或者指的是2月31日，那麼您將返回HTTP 400.若是您指望在實體主體中使用格式良好的XML，那麼同上。它沒法解析。

（1/2016）：在過去的五年中， WebDAV更具體的HTTP 422（不可處理的實體）已成爲HTTP 400的一個很是合理的替代方案。例如，請參閱它在JSON API中的使用。 但請注意，HTTP 422 還沒有進入HTTP 1.1， RFC-7231 。

Richardson和Ruby的RESTful Web服務包含一個很是有用的附錄，說明什麼時候使用各類HTTP響應代碼。 他們說：

400（「錯誤請求」）
重要性：高。
這是通用客戶端錯誤狀態，在沒有其餘4xx錯誤代碼適用時使用。 它一般在客戶端提交表示以及PUT或POST請求時使用，而且表示格式正確，但它沒有任何意義。 （第381頁）

和：

401（「未經受權」）
重要性：高。
客戶端嘗試在受保護的資源上運行，但未提供正確的身份驗證憑據。 它可能提供了錯誤的憑據，或者根本沒有。 憑證能夠是用戶名和密碼，API密鑰或認證令牌 - 不管所討論的服務是指望的。 客戶端一般會發出URI請求並接受401，所以它知道要發送什麼類型的憑據以及採用何種格式。 [...]

---

#5樓

來自RFC 4918（而且還記錄在http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml ）：

422（不可處理實體）狀態代碼表示服務器理解請求實體的內容類型（所以415（不支持的媒體類型）狀態代碼是不合適的），而且請求實體的語法是正確的（所以是400（錯誤請求） ）狀態代碼不合適）但沒法處理包含的指令。 例如，若是XML請求主體包含格式正確（即語法正確）但語義錯誤的XML指令，則可能發生此錯誤狀況。