我正在尝试用我正在开发的“类rest”API找出在不同场景中返回的正确状态代码。假设我有一个端点，允许以JSON格式POST'ing购买。它是这样的:
{
"account_number": 45645511,
"upc": "00490000486",
"price": 1.00,
"tax": 0.08
}
如果客户端发送给我“sales_tax”(而不是预期的“tax”)，我应该返回什么?目前，我要返回400分。但是，我开始质疑自己。我真的应该退回422吗?我的意思是，它是JSON(这是受支持的)，它是有效的JSON，它只是不包含所有必需的字段。
当前回答
400 Bad Request是用例的HTTP状态代码。该代码由HTTP/0.9-1.1 RFC定义。
由于格式错误，服务器无法理解请求 语法。客户端不应该重复请求 修改。
https://www.rfc-editor.org/rfc/rfc2616#section-10.4.1
422不可处理实体由RFC 4918 - WebDav定义。请注意，与400相比有轻微的差异，见下面引用的文本。
如果XML 请求主体包含格式良好的(即语法正确)，但是 语义错误的XML指令。
为了保持统一的接口，你应该只在XML响应的情况下使用422，你还应该支持Webdav扩展定义的所有状态码，而不仅仅是422。
https://www.rfc-editor.org/rfc/rfc4918#page-78
另见Mark Nottingham关于状态代码的帖子:
试图“深入”映射应用程序的每个部分是错误的。 转换成HTTP状态码;在大多数情况下，粒度级别你 想要的目标要粗糙得多。有疑问时，可以使用 通用状态代码200 OK, 400 Bad Request和500 Internal 没有更好的匹配时的服务错误。
如何看待HTTP状态码
其他回答
为反映截至2015年的状况:
从行为上讲，客户端和中介端对400和422响应代码的处理是一样的，因此使用哪一种响应代码并没有什么具体的区别。
然而，我希望看到400目前被更广泛地使用，而且HTTPbis规范提供的说明使它成为两种状态代码中更合适的一个:
HTTPbis规范明确了400的意图，不只是用于语法错误。现在使用了更广泛的短语“表示服务器不能或不愿处理由于客户机错误造成的请求”。 422是一个特定的WebDAV扩展，在RFC 2616或更新的HTTPbis规范中没有引用。
就上下文而言，HTTPbis是HTTP/1.1规范的修订版，试图澄清不清楚或不一致的地方。一旦达到批准状态，它将取代RFC2616。
400 Bad Request是用例的HTTP状态代码。该代码由HTTP/0.9-1.1 RFC定义。
由于格式错误，服务器无法理解请求 语法。客户端不应该重复请求 修改。
https://www.rfc-editor.org/rfc/rfc2616#section-10.4.1
422不可处理实体由RFC 4918 - WebDav定义。请注意，与400相比有轻微的差异，见下面引用的文本。
如果XML 请求主体包含格式良好的(即语法正确)，但是 语义错误的XML指令。
为了保持统一的接口，你应该只在XML响应的情况下使用422，你还应该支持Webdav扩展定义的所有状态码，而不仅仅是422。
https://www.rfc-editor.org/rfc/rfc4918#page-78
另见Mark Nottingham关于状态代码的帖子:
试图“深入”映射应用程序的每个部分是错误的。 转换成HTTP状态码;在大多数情况下，粒度级别你 想要的目标要粗糙得多。有疑问时，可以使用 通用状态代码200 OK, 400 Bad Request和500 Internal 没有更好的匹配时的服务错误。
如何看待HTTP状态码
首先，这是一个非常好的问题。
400坏请求-当请求中缺少关键信息时
例如:授权头或内容类型头。这是服务器理解请求所必需的。这可能因服务器而异。
422不可处理实体-当请求体不能被解析时。
这比400要轻。请求已经到达服务器。服务器已经确认请求的基本结构是正确的。但是无法解析或理解请求主体中的信息。
当请求体是JSON时，Content-Type: application/xml。
下面是一篇列出状态代码及其在REST api中的使用的文章。 https://metamug.com/article/status-codes-for-rest-api.php
案例研究:GitHub API
https://docs.github.com/en/rest/overview/resources-in-the-rest-api#client-errors
也许从著名的api复制是一个明智的想法:
There are three possible types of client errors on API calls that receive request bodies: Sending invalid JSON will result in a 400 Bad Request response: HTTP/1.1 400 Bad Request Content-Length: 35 {"message":"Problems parsing JSON"} 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"} 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" } ] }
422 Unprocessable Entity Explained Updated: March 6, 2017 What Is 422 Unprocessable Entity? A 422 status code occurs when a request is well-formed, however, due to semantic errors it is unable to be processed. This HTTP status was introduced in RFC 4918 and is more specifically geared toward HTTP extensions for Web Distributed Authoring and Versioning (WebDAV). There is some controversy out there on whether or not developers should return a 400 vs 422 error to clients (more on the differences between both statuses below). However, in most cases, it is agreed upon that the 422 status should only be returned if you support WebDAV capabilities. A word-for-word definition of the 422 status code taken from section 11.2 in RFC 4918 can be read below. 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. The definition goes on to say: For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions. 400 vs 422 Status Codes Bad request errors make use of the 400 status code and should be returned to the client if the request syntax is malformed, contains invalid request message framing, or has deceptive request routing. This status code may seem pretty similar to the 422 unprocessable entity status, however, one small piece of information that distinguishes them is the fact that the syntax of a request entity for a 422 error is correct whereas the syntax of a request that generates a 400 error is incorrect. The use of the 422 status should be reserved only for very particular use-cases. In most other cases where a client error has occurred due to malformed syntax, the 400 Bad Request status should be used.
https://www.keycdn.com/support/422-unprocessable-entity/
