将400状态码用于任何其他目的，而不是表示请求是畸形的，这是完全错误的。

如果请求有效负载包含一个不能被解析为application/json的字节序列(如果服务器期望该数据格式)，则适当的状态代码为415:

的实体导致服务器拒绝为请求提供服务 所请求的资源不支持该请求的格式 请求的方法。

如果请求负载在语法上正确但语义上不正确，则可以使用非标准的422响应代码或标准的403状态代码:

服务器理解请求，但拒绝执行。 授权没有帮助，请求不应该重复。

从w3.org

10.4.1 400个错误请求 由于格式错误，服务器无法理解请求 语法。客户端不应该重复请求 修改。

想想期望。

作为客户端应用程序，您希望知道服务器端是否出现了问题。如果服务器需要在blah缺失或requestedResource值不正确时抛出错误，那么400错误将是合适的。

这让我想起了和别人的对话，“我理解-我只是不同意”

400表示服务器没有理解

200表示服务器完全理解并完全处理了请求。

当服务器返回200时，它就在说:“我理解您的请求，我处理了它，没有出现意外错误，这是我的正确响应。”

200表示您可以信任响应中发送的答案。也许答案是“罗马人是不被允许的”——但这仍然是一个正确的答案，没有任何意想不到的问题。

200没有表达关于预期错误或已处理异常的任何信息——因为这不是消息传输过程的一部分。这些是关于HTTP的状态代码，即传输本身的状态。

我认为应该避免模糊“运输/通信”和“处理”之间的界限。

对于那些喜欢用HTTP代码来表示处理中的问题(“我不同意”部分)的人来说，409冲突似乎最适用于“罗马人不允许”。 RFC 7231 409冲突

冲突在很大程度上意味着“缺乏一致”，对吧?

无论您选择什么HTTP响应代码，似乎每个人都同意您的响应应该解释为什么失败，以及如何解决它。在罗曼的情况下，可能返回字段可接受的值列表?

400表示请求格式不正确。换句话说，客户端发送给服务器的数据流没有遵循规则。

在带有JSON有效负载的REST API的情况下，400通常(我认为是正确的)用于根据服务的API规范指示JSON在某种程度上是无效的。

根据这种逻辑，您提供的两个场景都应该是400s。

假设这是XML而不是JSON。在这两种情况下，XML都不会通过模式验证——要么是因为元素未定义，要么是因为元素值不正确。这是个糟糕的要求。这里也是一样。

这两种情况都不是“语法畸形”。语义是错误的。因此，恕我直言，400是不合适的。相反，返回一个200和某种类型的错误对象，如{"error": {"message": "Unknown request keyword"}}或其他。

考虑客户机处理路径。语法错误(例如，无效的JSON)是程序逻辑中的错误，换句话说，是某种类型的错误，应该以类似403的方式进行相应的处理;换句话说，有不好的事情发生了。

另一方面，参数值中的错误是语义错误，可能是由于用户输入验证不当造成的。这不是一个HTTP错误(尽管我认为它可能是一个422)。处理路径会有所不同。

例如，在jQuery中，我不希望编写一个单独的错误处理程序来处理500和一些特定于应用程序的语义错误。其他框架，比如Ember，也把400秒和500秒的HTTP错误视为重大错误，要求程序员检测发生了什么，并根据它是否是“真正的”错误进行分支。