客户端错误请求的 400 与 422

Question

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

The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).

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

The 400 (Bad Request) status code has been relaxed so that it isn't
limited to syntax errors. (Section 6.5.1)

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

另一方面，其他人说最好使用 422（不可处理的实体）。虽然这更侧重于语义，但它仅在 [RFC 4918][2] 中列出，它是 http/1.1 的 webDAV 扩展

The 422 (Unprocessable Entity) status code means the server
understands the content type of the request entity (hence a
415(Unsupported Media Type) status code is inappropriate), and the
syntax of the request entity is correct (thus a 400 (Bad Request)
status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML
request body contains well-formed (i.e., syntactically correct), but
semantically erroneous, XML instructions.

我可以使用这个 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。我比以往任何时候都更困惑 >.< 虽然有一部分我认为 400 是更好的选择，因为它包含在 RFC 文档中，而 422 不是。不过我可能是错的。

Answer 1

Can I use this WebDAV extension codes to handle my HTTP requests? In the case of 422, can I use it even though it's not in the core HTTP codes.

HTTP 是一种可扩展协议，422 is registered in IANA, which makes it a standard status code. So nothing stops you from using 422 在您的应用程序中。

Should I use 400 or 422 for my client error?

视情况而定，但您可以同时使用两者。通常，使用 400 to indicate syntax errors in the payload or invalid parameters in the URL. And use 422 表示负载中存在 语义 问题。

例如，请参阅 approach used by the GitHub v3 API:

Client errors

There are three possible types of client errors on API calls that receive request bodies:

1. Sending invalid JSON will result in a 400 Bad Request response.

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

2. Sending the wrong type of JSON values will result in a 400 Bad Request response.

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

3. Sending invalid fields will result in a 422 Unprocessable Entity response.

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

---

选择最合适的4xx状态码

Michael Kropat put together a set of decision charts 有助于确定每种情况的最佳状态代码。请参阅以下 4xx 状态代码：

HTTP APIs

的问题详细信息

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

中报告错误的一个很好的起点

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