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

2018-05-31 11:27:00

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

如果在requestedResource字段存在的情况下将其视为400 ，但"Roman"对于此字段是无效的值？

[{requestedResource:"Roman"}]

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

[{blah:"Roman"}]

400意味着请求格式不正确。换句话说，客户端发送到服务器的数据流并不遵循规则。

对于具有JSON有效负载的REST API，根据服务的API规范，400通常用于表示JSON在某种程度上无效。

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

想象一下，这是XML而不是JSON。在这两种情况下，XML都不会通过模式验证 - 或者是因为未定义的元素或不正确的元素值。这将是一个不好的要求。这里同样如此。

从w3.org

10.4.1 400错误请求

由于格式错误，服务器无法理解请求。客户端不应该在没有修改的情况下重复请求。

选择一个HTTP响应代码是一件非常容易的事情，可以用简单的规则来描述。唯一经常被遗忘的棘手的部分是RFC 7231的6.5节：

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

规则如下：

如果请求成功，则返回2xx代码（3xx用于重定向）。如果服务器上存在内部逻辑错误，则返回5xx。如果客户端请求中有任何错误，则返回4xx代码。

查看所选类别的可用响应代码。如果其中一个名称与您的情况匹配得很好，您可以使用它。否则只需回退到x00代码（200,400,500）。如果您怀疑，则回退到x00代码。

返回响应正文中的错误描述。对于4xx代码，它必须包含足够的信息，以便客户开发人员了解原因并修复客户端。对于5xx，由于安全原因，不得透露任何细节。

如果客户端需要区分不同的错误并根据它产生不同的反应，请定义一种机器可读和可扩展的错误格式，并在您的API中的任何地方使用它。从一开始就做好这个做法是很好的做法。

请记住，客户端开发人员可能会做一些奇怪的事情，并试图解析您返回的字符串作为人类可读的描述。而通过改变字符串，你将打破这种写得不好的客户端。因此，请始终提供机器可读的说明，并尽量避免报告文本中的其他信息。

所以在你的情况下，如果从用户输入中获得“Roman”并且客户端必须有特定的反应，我会返回400错误和类似的情况：

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

或者更通用的错误，如果这种情况在客户端中是一个错误的逻辑错误，并且不是所期望的，除非开发者犯了错误：

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

链接地址: http://www.djcxy.com/p/7057.html