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

Question

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

如果这被视为400其中requestedResource场存在,但"Roman"对于这方面的无效值？

[{requestedResource:"Roman"}] 

如果这被视为400其中"blah"场完全不存在吗？

[{blah:"Roman"}]

Answer 1

400表示请求格式错误.换句话说,客户端发送到服务器的数据流不遵循规则.

在具有JSON有效负载的REST API的情况下,通常我会说400,用于表示JSON根据服务的API规范以某种方式无效.

根据这个逻辑,你提供的两个场景都应该是400.

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

Answer 2

来自w3.org

10.4.1 400错误请求

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

Answer 3

选择HTTP响应代码是一项非常容易的任务,可以通过简单的规则来描述.经常被遗忘的唯一棘手的部分是来自RFC 7231的第6.5段:

除了在响应HEAD请求时,服务器应该发送一个表示,其中包含错误情况的解释,以及它是暂时的还是永久的.

规则如下:

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

所以在你的情况下,如果从用户输入获得"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

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

400表示服务器不理解

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

当服务器返回 200 时，它表示：“我理解您的要求，我处理它时没有出现意外错误，这是我的正确响应”

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

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

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

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

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

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

Answer 7

想想期望.

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

Answer 8

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

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

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

Answer 9

作为补充，对于那些可能遇到与我相同问题的人，我正在使用$.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); 
    }
});

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