400 和 422 HTTP 狀態碼的區別

Question

如果 HTTP 請求負載缺少必需屬性，響應代碼必須是 400 或 422，有很多討論。

我還不清楚其中的區別。

請使用邏輯場景/示例建議何時使用 400 或 422 HTTP 狀態代碼。

Answer 1

我知道這個問題已經有將近一年的歷史了，但我想我會根據我自己在近 400 個微服務中設計和構建一個非常大的 API 域的經驗添加一個答案。

理想情況下，API 應遵循 Postel 定律並對其接收的內容保持寬容。 這幫助我們澄清了何時使用400以及何時使用422 。

在上面的答案中，我們將示例 400 響應視為 422 響應。 為什么？ 因為我們可以通過忽略它來容忍“未知”屬性。 但是缺少必需的<date>字段，因此我們將返回一個 422，其中包含一個錯誤指示。

如果消費者通過application/xml內容類型下的 JSON 有效負載發送或 XML 請求無效（即，他們具有<date>2020-01-07</dat>字段），則會引發 400 響應。

這種方法給我們帶來的一個優勢是，我們可以為 422 個響應定義不同的響應契約，同時允許 400 個響應保持一個相當通用的“你想問的 WTF？” 回應。 我們的422個回應包含列出每個請求限制或要求已被打破錯誤信息的集合。

我們還發現這種方法對於我們的 UX 人員特別有用，他們可以向 API 提交表單並返回帶有人類可讀錯誤的響應，他們可以直接映射回表單字段（即點擊提交但未填寫）必填字段將生成 422 響應，其中包含一條消息，說明該屬性是必需的）。

Answer 2

據我所知，400 用於語法錯誤的請求，422 用於語義錯誤的請求。 如果您期望像這樣的請求

...
  <name>test name</name>
  <date>2020-01-07</date>
...

400 將是：

...
  <name>test name</name>
  <dateString>2020-01-07</dateString>
...

422 將是：

...
  <name>test name</name>
  <date>hello</date>
...

我只使用 400，因為HTTP/1.1 RFC7231 中沒有定義 422