我正在努力确定在我正在开发的“类REST” API中不同场景下应该返回哪个正确的状态码。假设我有一个允许以JSON格式POST购买的终端点。它看起来像这样:
{
"account_number": 45645511,
"upc": "00490000486",
"price": 1.00,
"tax": 0.08
}
在您提问时（以及我的原始答案），RFC 7231还不存在；那时我反对使用400 Bad Request，因为RFC 2616说（强调是我的）：
由于语法错误，服务器无法理解请求。
而您描述的请求是语法上有效的JSON封装在语法上有效的HTTP中，因此服务器没有关于请求的语法问题。
现在看来，400 Bad Request似乎是您的用例中最好的HTTP/1.1状态码。
然而，正如Lee Saferite在评论中指出的那样, RFC 7231，取代了RFC 2616，没有包括该限制:
400（错误请求）状态代码表示服务器由于认为是客户端错误（例如，格式错误的请求语法，无效的请求消息框架或欺骗性请求路由）而无法或不会处理请求。
然而，在重新表述之前（或者如果你想挑剔的话，RFC 7231现在只是一个提议标准），对于你的使用情况，422 Unprocessable Entity似乎不是一个错误的HTTP状态码，因为正如RFC 4918的介绍所说：
虽然HTTP/1.1提供的状态码足以描述WebDAV方法遇到的大多数错误条件，但有些错误并不很容易归入现有的类别。本规范定义了为WebDAV方法开发的额外状态码（第11节）
而关于422的描述则说：
若在原标准中使用明确无法涵盖该情况的错误代码和从扩展中获取并描述该情况的错误代码之间进行选择，我会选择后者。
此外，RFC 4918第21.4节提到了IANA超文本传输协议(HTTP)状态码注册表，其中可以找到422。
我建议HTTP客户端或服务器完全可以在正确使用的前提下使用该注册表中的任何状态码。
400 Bad Request即可！案例研究: 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" } ] }
请求实体的语法是正确的，但无法处理其中包含的指令。这意味着有效载荷格式正确，服务器理解了请求。但由于其他原因，无法继续处理。 所以我同意@leo_cape。 这个答案是不正确的。 - undefined
400 Bad Request是你的使用场景下合适的HTTP状态码，该代码由HTTP / 0.9-1.1 RFC定义。
由于格式不正确，服务器无法理解请求。客户端应该在未经修改的情况下不重复请求。
https://www.rfc-editor.org/rfc/rfc2616#section-10.4.1
422 Unprocessable Entity由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 Service Error。
由于你的请求中“语法”一词的定义不同，因此没有正确答案。最重要的是：
在大家抨击我说这里没有对错答案之前，请允许我解释一下我的结论是如何得出的。
在这个特定的例子中，OP的问题是关于一个包含与预期不同的键的JSON请求。现在，根据自然语言的角度来看，接收到的键名非常相似，但它是严格不同的，因此（通常）不能被机器识别为等价的。
正如我上面所说，决定因素是“语法”的含义。如果请求以Content Type为“application/json”发送，则是的，该请求在语法上是有效的，因为它是有效的JSON语法，但在语义上无效，因为它与预期的不匹配（假设严格定义了有关该请求是否语义上有效的标准）。
另一方面，如果请求以更具体的自定义Content Type的形式发送，例如“application/vnd.mycorp.mydatatype+json”，则该请求很可能在语法上无效，因此会返回400响应（也许说明了预期需要哪些字段）。
在这种情况下，由于“键”不正确，而不是“值”，如果有关于有效键的规范，则存在“语法”错误。如果没有关于有效键的规范，或者错误出现在值上，则是“语义”错误。
您的情况：从REST的角度来看，HTTP 400是您的情况下正确的状态代码，因为发送sales_tax而不是tax在语法上是不正确的，尽管它是一个有效的JSON。当将JSON映射到对象时，大多数服务器端框架通常会强制执行此操作。但是，有一些REST实现会忽略JSON对象中的新key。在这种情况下，可以通过服务器端强制执行自定义content-type规范以仅接受有效字段。
422的理想情况：
在理想的情况下，如果服务器了解请求实体的内容类型并且请求实体的语法正确但无法处理数据，因为其在语义上是错误的，则发送422作为响应通常是首选并且可接受的。
400优于422的情况：
请记住，响应代码422是扩展的HTTP（WebDAV）状态代码。仍然有一些HTTP客户端/前端库没有准备好处理422。对于他们来说，这很简单，就像“HTTP 422是错误的，因为它不是HTTP”一样。从服务的角度来看，400并不是非常具体的。
在企业架构中，服务大多部署在服务层（如SOA、IDM等）上。它们通常为多个客户端提供服务，从非常旧的本地客户端到最新的HTTP客户端。如果其中一个客户端无法处理HTTP 422，则选项是要求客户端升级或将响应代码更改为HTTP 400，适用于所有人。根据我的经验，这在今天很少见，但仍然有可能发生。因此，在决定HTTP响应代码之前，始终需要仔细研究您的架构。
为了处理这种情况，服务层通常使用版本控制或设置配置标志以严格遵循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 - 请求验证失败，例如数据缺失、类型错误等，因此被赋予了400状态。
422 - 请求验证通过，但操作过程失败，因为请求数据或其中一部分向操作发生错误，但已处理并赋予了422状态。
首先，这是一个非常好的问题。
例如，授权头或内容类型头。服务器绝对需要这些信息才能理解请求。这可能因服务器而异。
这比400轻微。请求已经到达服务器。服务器已经确认请求的基本结构正确。但是请求正文中的信息无法解析或理解。
例如，当请求正文为JSON时，Content-Type: application/xml。
这里有一篇文章列出了状态码及其在REST API中的使用。 https://metamug.com/article/status-codes-for-rest-api.php