客户端错误请求的 400 与 422

Question

我已经阅读了很多关于正确的 http 状态代码以返回客户端请求错误的帖子和文章。 其他人建议使用 400，因为它已在 RFC 7231 中重新定义，但我不确定给出的示例是否涵盖了我脑海中的所有客户端错误，因为这些示例是句法的。

400（Bad Request）状态码表示服务器不能或 由于某些被认为是 客户端错误（例如，格式错误的请求语法、无效请求
消息框架或欺骗性请求路由）。

我确实在 rfc 7231 的附录 B 中找到了这个声明：

400（错误请求）状态代码已放宽，因此它不是
仅限于语法错误。 （第 6.5.1 节）

这是否意味着我可以将任何类型的客户端错误视为错误请求？将 400 用于客户端请求并在消息中指定更具体的错误会更好吗？

另一方面，其他人说最好使用 422 (Unprocessable Entity)。虽然这更侧重于语义，但它只列在 [RFC 4918][2] 中，它是 http/1.1 的 webDAV 扩展

422（不可处理实体）状态码表示服务器
了解请求实体的内容类型（因此 a
415（不支持的媒体类型）状态码不合适），
请求实体的语法正确（因此为 400（错误请求）
状态码不合适）但无法处理包含的 指示。例如，如果 XML
请求正文包含格式正确（即语法正确），但
语义错误的 XML 指令。

我可以使用这个 webDAV 扩展代码来处理我的 http 请求吗？在 422 的情况下，即使它不在核心 http 代码中，我也可以使用它吗？

对于客户端错误，我应该使用 400 还是 422？

这是我想到的可能的客户端错误：

1.) Invalid parameter. The client provided parameters but are found invalid. Example: I said that the userId is 1, but when I checked there's no userId of 1. Another example of invalid parameter is wrong data type.
2.) Missing required parameters
3.) Let's say I need to hash a value based on given params and it failed 
4.) Blocked content is being used. Like, i want to apply for membership and i passed the userId of 1. However, userId of one is blocked / deactivated
5.) When I try to delete an entry but the entry is still being used in another table. 
6.) Let's say i require a signature in my payload and the signature does not match when recalculated in the backend
7.) Let's say I have a value that counts a specific attribute like "shares" and it has reached the maximum value like 10.
etc...

任何信息丰富的回应将不胜感激。非常感谢，伙计们！

更新：我检查了 google api 错误，但它们没有使用 422。另一方面，Twitter 使用 422。我比以往任何时候都更加困惑 >.

Answer 1

我可以使用这个 WebDAV 扩展代码来处理我的 HTTP 请求吗？在422的情况下，即使它不在核心HTTP代码中，我也可以使用它吗？

HTTP 是一种可扩展的协议，422 是registered in IANA，这使其成为标准状态代码。因此，没有什么能阻止您在应用程序中使用 422。

我应该使用400 还是422 来处理我的客户端错误？

这取决于，但你可以同时使用。通常，使用400 来指示负载中的语法 错误或URL 中的无效参数。并使用422 指示有效负载中的语义问题。

作为示例，请参阅GitHub v3 API 使用的approach：

Client errors

在接收请求正文的 API 调用中存在三种可能的客户端错误类型：

1. 发送无效的 JSON 将导致 400 错误请求响应。

    HTTP/1.1 400 Bad Request
    Content-Length: 35
   
    {"message":"Problems parsing JSON"}
   

2. 发送错误类型的 JSON 值将导致 400 错误请求响应。

    HTTP/1.1 400 Bad Request
    Content-Length: 40
   
    {"message":"Body should be a JSON object"}
   

3. 发送无效字段将导致422 Unprocessable Entity 响应。

    HTTP/1.1 422 Unprocessable Entity
    Content-Length: 149
   
    {
      "message": "Validation Failed",
      "errors": [
        {
          "resource": "Issue",
          "field": "title",
          "code": "missing_field"
        }
      ]
    }
   

---

挑选最合适的4xx状态码

Michael Kropat 将set of decision charts 放在一起有助于确定每种情况的最佳状态代码。请参阅以下4xx 状态代码：

HTTP API 的问题详情

HTTP 状态代码有时不足以传达有关错误的足够信息以提供帮助。 RFC 7807 定义了简单的 JSON 和 XML 文档格式，以通知客户端 HTTP API 中的问题。这是报告 API 错误的绝佳起点。

它还定义了application/problem+json 和application/problem+xml 媒体类型。