13

我已经阅读了很多关于正确的 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（Unprocessable Entity）状态码意味着服务器
理解请求实体的内容类型（因此
415（Unsupported Media Type）状态码是不合适的），并且
请求实体的语法是正确的（因此是 400（Bad Request） )
状态码不合适）但无法处理包含的指令。例如，如果 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。我比以往任何时候都更加困惑。< 虽然我的一部分人认为 400 是更好的选择，因为它包含在内在 RFC 文档中，422 不是。不过我可能是错的。

4

1 回答 1

36

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

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

我应该使用400还是422我的客户错误？

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

例如，请参阅GitHub v3 API使用的方法：

客户端错误

接收请求正文的 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实体响应。

     HTTP/1.1 422 Unprocessable Entity
 Content-Length: 149

 {
   "message": "Validation Failed",
   "errors": [
     {
       "resource": "Issue",
       "field": "title",
       "code": "missing_field"
     }
   ]
 }

选择最合适的4xx状态码

Michael Kropat整理了一组决策图表，帮助确定每种情况的最佳状态代码。4xx有关状态代码，请参见以下内容：

HTTP 4xx 状态码

HTTP API 的问题详细信息

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

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

于 2018-08-30T13:47:07.620 回答