Question

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

是否应将此视为400，其中requestedResource字段存在，但"Roman"是此字段的无效值？

[{requestedResource:"Roman"}]

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

[{blah:"Roman"}]

Answer 1

A 400表示请求格式错误。换句话说，客户端发送到服务器的数据流不符合规则。

对于带有JSON有效负载的REST API，通常情况下，我会说400，用于表示根据服务的API规范，JSON在某种程度上无效。

按照这种逻辑，你提供的两种情景都应该是400。。

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

Answer 2

来自w3.org

10.4.1 400错误请求

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

Answer 3

选择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"
}

Answer 4

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

考虑客户端处理路径。语法错误（例如无效的JSON）是程序逻辑中的错误，换句话说是某种错误，应该以类似403的方式相应地处理，比如说;换句话说，坏事出了问题。

另一方面，参数值中的错误是语义错误，可能是因为用户输入验证不当。它不是HTTP错误（虽然我认为它可能是422）。处理路径会有所不同。

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

Answer 5

将400状态代码用于指示请求格式错误之外的任何其他目的都是完全错误的。

如果请求有效负载包含无法解析为application/json的字节序列（如果服务器需要数据格式），则相应的状态代码为415：

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

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

服务器理解请求，但拒绝履行请求。授权无效，请求不应重复。

Answer 6

考虑期望。

作为客户端应用，您希望知道服务器端是否出现问题。如果服务器在blah丢失或requestedResource值不正确时错误发生错误，则错误发生400错误。

Answer 7

首先检查它可能是错误的URL，如果它是正确的，那么检查你发送的请求正文，可能的原因是你发送的请求缺少正确的语法。

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

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

Answer 8

作为补充，对于那些可能遇到与我相同的问题的人，我正在使用$.ajax将表单数据发布到服务器，并且最初也遇到了400错误。

假设我有一个javascript变量，

            var formData = {
                "name":"Gearon",
                "hobby":"Be different"
                };

请勿将变量formData直接用作键data的值，如下所示：

            $.ajax({
                type: "post",
                dataType: "json",
                url: "http://localhost/user/add",
                contentType: "application/json",
                data: formData,
                success: function(data, textStatus){
                    alert("Data: " + data + "\nStatus: " + status); 
                }
            });

相反，使用JSON.stringify封装formData，如下所示：

            $.ajax({
                type: "post",
                dataType: "json",
                url: "http://localhost/user/add",
                contentType: "application/json",
                data: JSON.stringify(formData),
                success: function(data, textStatus){
                    alert("Data: " + data + "\nStatus: " + status); 
                }
            });

无论如何，正如其他人所说明的那样，该错误是由于服务器无法识别导致语法格式错误的请求，我只是在实践中提出一个实例。希望对某人有帮助。

Answer 9

这让我想起了与他人的常见对话，“我明白 - 我只是不同意”

400 表示服务器不理解

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

当服务器返回 200 时，它说，“我理解你的要求，我处理它没有意外错误，这是我的正确响应”

200 表示您可以信任响应中发送的答案。也许答案是“不允许使用罗马字符”——但它仍然是一个正确的答案，没有任何意外问题。

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

我认为应该避免混淆“传输/通信”与“处理”之间的界限。

对于那些喜欢用 HTTP 代码来表示处理问题的人（“我不同意”部分），似乎 409 冲突最适用于“不允许使用罗马字符”
RFC 7231 409 Conflict

冲突几乎意味着“缺乏共识”，对吗？

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

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

9 个答案: