400 BAD请求HTTP错误代码的含义？

我有一个JSON请求，我发布到一个HTTP URL。

这应该被视为400 where requestedResource字段存在，但"Roman"是这个领域的无效值？

 [{requestedResource:"Roman"}]

这应该被视为400 ，其中"blah"字段根本不存在？

 [{blah:"Roman"}]

400意味着请求是畸形的。换句话说，客户端发送给服务器的数据stream并不遵循规则。

对于带有JSON有效负载的REST API，根据服务的API规范，在某些情况下，通常会使用400个字符来正确表示JSON无效。

按照这个逻辑，你提供的场景应该是400。

想象一下，这是XML而不是JSON。在这两种情况下，XML都不会通过模式validation – 要么是因为未定义的元素，要么是不正确的元素值。这将是一个不好的要求。这里一样的交易。

从w3.org

10.4.1 400错误的请求

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

select一个HTTP响应代码是相当简单的任务，可以用简单的规则来描述。唯一经常被遗忘的棘手的部分是RFC 7231的6.5节：

除了响应HEAD请求外，服务器应该发送一个包含错误情况解释的表示，以及它是临时还是永久状态。

规则如下：

如果请求成功，则返回2xx代码（3xx用于redirect）。如果服务器上有内部逻辑错误，则返回5xx。如果客户端请求有任何错误，则返回4xx代码。
查看所选类别的可用响应代码。如果其中一个名称与您的情况相匹配，则可以使用它。否则只是回退到x00代码（200,400,500）。如果您怀疑，则回退到x00代码。
返回响应正文中的错误描述。对于4xx代码，它必须包含足够的信息，以便客户开发人员了解原因并修复客户端。对于5xx由于安全原因，不得透露任何细节。
如果客户端需要根据不同的错误区分不同的错误，请定义一个机器可读和可扩展的错误格式，并在您的API中使用它。从一开始就是很好的做法。
请记住，客户端开发人员可能会做一些奇怪的事情，并试图parsing您返回的string作为人类可读的描述。而通过改变string，你将打破如此糟糕的客户端。因此，请始终提供机器可读的说明，并尽量避免报告文本中的其他信息。

所以在你的情况下，我已经返回了400错误，如果从用户input中获得“Roman”，客户端必须有特定的反应：

 { "error_type" : "unsupported_resource", "error_description" : "\"Roman\" is not supported" }

或更通用的错误，如果这种情况是一个错误的客户端，并不是预期的，除非开发人员做错了：

 { "error_type" : "malformed_json", "error_description" : "\"Roman\" is not supported for \"requestedResource\" field" }

在任何情况下都不是“语法错误”。这是错误的语义。因此，恕我直言，400是不合适的。相反，返回一个200以及一些错误对象，例如{ "error": { "message": "Unknown request keyword" } }或者其他任何东西都是合适的。

考虑客户端处理path。语法上的错误（例如无效的JSON）是程序逻辑中的错误，换句话说就是某种错误，并且应该按照类似于403的方式来处理。换句话说，坏事出了问题。

另一方面，参数值中的错误是语义错误，可能是由于validation用户input错误。这不是一个HTTP错误（虽然我想它可能是一个422）。处理path会有所不同。

例如，在jQuery中，我宁愿不必编写一个处理诸如500和某些特定于应用程序的语义错误之类的error handling程序。其他的框架，Ember也是一样，把像400s和500s这样的HTTP错误同样视为大胖子的失败，要求程序员根据是否是“真实的”错误来检测正在发生的事情和分支。

将400状态码用于表示请求格式不正确的任何其他目的只是显然是错误的。

如果请求有效载荷包含不能被parsing为application/json的字节序列（如果服务器期望这种数据格式），那么适当的状态码是415 ：

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

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

服务器了解请求，但拒绝履行。授权不起作用，请求不应重复。

考虑期望。

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

首先检查它可能是错误的URL，如果它是正确的，然后检查您正在发送的请求正文，可能的原因是您要发送的请求缺less正确的语法。

详细说明，检查请求string中的特殊字符。如果是（特殊字符）被使用这是这个错误的根本原因。

尝试复制请求并分析每个标签数据。