案例研究: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" } ] }

没有正确的答案，因为这取决于对请求的“语法”的定义。最重要的是你:

一致地使用响应代码 在响应体中包含尽可能多的额外信息，以帮助使用API的开发人员弄清楚发生了什么

在大家因为我说这个问题没有正确或错误的答案而责怪我之前，让我解释一下我是如何得出这个结论的。

在这个特定的例子中，OP的问题是关于一个包含不同于预期键的JSON请求。现在，从自然语言的角度来看，接收到的键名与预期的键名非常相似，但严格来说，它是不同的，因此(通常)机器不会认为它们是等效的。

如上所述，决定因素是语法的含义。如果请求是以application/json的内容类型发送的，那么是的，请求在语法上是有效的，因为它是有效的json语法，但在语义上是无效的，因为它不匹配预期的内容。(假设有一个严格的定义，什么使问题中的请求在语义上有效或无效)。

另一方面，如果请求是以更特定的自定义内容类型(如application/vnd.mycorp)发送的。mydatatype+json，也许，确切地指定了期望的字段，那么我会说请求很容易在语法上无效，因此响应为400。

在这个问题中，由于键是错误的，而不是值，因此如果存在有效键是什么的规范，就会出现语法错误。如果没有有效键的规范，或者错误是带有值的，那么它将是语义错误。

您的案例:从REST的角度来看，HTTP 400是您案例的正确状态代码，因为发送sales_tax而不是tax在语法上是不正确的，尽管它是一个有效的JSON。在将JSON映射到对象时，大多数服务器端框架通常会强制执行这一点。然而，有一些REST实现忽略JSON对象中的new键。在这种情况下，服务器端可以强制使用只接受有效字段的自定义内容类型规范。

422的理想场景:

在理想情况下，如果服务器理解请求实体的内容类型，并且请求实体的语法正确，但由于语义错误而无法处理数据，则首选422，并且通常可以接受将其作为响应发送。

400 / 422的情况:

记住，响应代码422是一个扩展的HTTP (WebDAV)状态码。仍然有一些HTTP客户端/前端库还没有准备好处理422。对他们来说，这就像“HTTP 422是错误的，因为它不是HTTP”一样简单。从服务的角度来看，400并不十分具体。

In enterprise architecture, the services are deployed mostly on service layers like SOA, IDM, etc. They typically serve multiple clients ranging from a very old native client to a latest HTTP clients. If one of the clients doesn't handle HTTP 422, the options are that asking the client to upgrade or change your response code to HTTP 400 for everyone. In my experience, this is very rare these days but still a possibility. So, a careful study of your architecture is always required before deciding on the HTTP response codes.

为了处理类似的情况，服务层通常使用版本控制或设置配置标志对严格符合HTTP的客户端发送400，对其余客户端发送422。通过这种方式，它们为现有的使用者提供了向后兼容性支持，但同时也为新客户提供了使用HTTP 422的能力。

RFC7321的最新更新说:

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).

这证实了服务器可以为无效请求发送HTTP 400。400不再仅仅是语法错误，但是，422仍然是一个真正的响应，前提是客户端可以处理它。

首先，这是一个非常好的问题。

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/