客户端错误请求的400 vs 422

Question

我已经阅读了许多有关正确的HTTP状态代码的帖子和文章，以返回客户请求错误。 其他人建议使用RFC 7231中已重新定义的400，尽管由于示例是语法性的，所以我不确定给出的示例是否覆盖了我所有的客户错误。

  

400（错误请求）状态代码表示服务器无法执行以下操作：   由于某些原因而不会处理请求   客户端错误（例如格式错误的请求语法，无效的请求
  邮件框架或欺骗性请求路由）。

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

  

已放宽了400（错误请求）状态码，使之不会出现
  限于语法错误。 （第6.5.1节）

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

另一方面，其他人则说最好使用422（不可处理实体）。尽管它更着重于语义，但仅在RFC 4918中列出，它是http / 1.1的webDAV扩展名

  

422（不可处理实体）状态代码表示服务器
  了解请求实体的内容类型（因此，
  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。我比以往任何时候都更加困惑>。<尽管我有些人认为400是更好的选择，它包含在RFC文档中，而422没有。我可能是错的。

Answer 1

  

我可以使用此WebDAV扩展代码来处理我的HTTP请求吗？对于422，即使它不在核心HTTP代码中，我也可以使用它。

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

  

我应该使用400还是422来解决客户端错误吗？

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

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

  

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无法处理的实体响应。

   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媒体类型。