逻辑错误的 HTTP 400（错误请求），不是格式错误的请求语法

Question

HTTP/1.1 specification (RFC 2616)对status code 400, Bad Request (§10.4.1)的含义有以下说法：

请求无法被理解 服务器由于语法错误。 客户不应该重复 无需修改即可请求。

如今，在一些基于 HTTP 的 API 中似乎有一种普遍的做法，即使用 400 来表示请求的逻辑而不是语法错误。我的猜测是 API 这样做是为了区分 400（客户端诱导）和 500（服务器诱导）。使用 400 表示非句法错误是否可以接受或不正确？如果可以接受，是否有关于 RFC 2616 的注释参考，可以更深入地了解 400 的预期用途？

例子：

• Google Data Protocol, Protocol Reference, HTTP Status Codes

Answer 1

想到状态 422 (RFC 4918, Section 11.2)：

422（Unprocessable Entity）状态码表示服务器理解请求实体的内容类型（因此 415（Unsupported Media Type）状态码是不合适的），并且请求实体的语法是正确的（因此 400 （错误请求）状态代码不合适）但无法处理包含的指令。例如，如果 XML 请求正文包含格式正确（即语法正确）但语义错误的 XML 指令，则可能会发生这种错误情况。

Answer 2

截至目前，HTTPbis 规范的最新草案，旨在替换和使 RFC 2616 过时，states：

400（Bad Request）状态码表示服务器不能或 不会处理请求，因为接收到的语法无效， 荒谬的，或超出服务器愿意的某些限制 处理。

此定义当然仍会发生变化，但它认可了广泛使用的以 400 响应逻辑错误的做法。

Answer 3

HTTPbis 将解决 400 Bad Request 的措辞，以便它也涵盖逻辑错误。所以 400 将包含 422。

来自https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p2-semantics-18#section-7.4.1
“由于客户端错误（例如，格式错误的语法），服务器无法或不会处理请求”

Answer 4

尽管我也一直使用 400 来表示逻辑错误，但我不得不说在这种情况下返回 400 是错误的，因为规范读取的方式。这就是我这么认为的原因，逻辑错误可能是与另一个实体的关系失败或不满意，并且对另一个实体进行更改可能会导致相同的确切结果稍后通过。就像在该员工不存在时尝试（完全假设）将员工添加为部门成员（逻辑错误）。将员工添加为成员请求可能会失败，因为员工不存在。但是，在将员工添加到系统后，同样的请求可能会通过。

只要我的 2 美分……我们现在需要律师和法官来解释 RFC 中的语言 :)

谢谢你， 维什

Answer 5

可以说，您的请求中包含不正确的数据是语法错误，即使您在 HTTP 级别（请求行、标头等）的实际请求在语法上是有效的。

例如，如果一个 Restful Web 服务被记录为接受具有自定义 XML 内容类型 application/vnd.example.com.widget+xml 的 POST，而您发送的是一些乱码纯文本或二进制文件，则将其视为语法错误似乎是合理的- 您的请求正文不是预期的形式。

不过，我不知道有任何官方引用来支持这一点，像往常一样，这似乎是为了解释 RFC 2616。

更新：注意RFC 7231 §6.5.1中的修改措辞：

400 (Bad Request) 状态码表示服务器不能或不会处理请求，原因是被认为是客户端错误，例如请求语法格式错误、请求消息帧无效或请求路由具有欺骗性）。

似乎比现在已经过时的RFC 2616 §10.4.1 更支持这个论点，RFC 2616 §10.4.1 只是说：

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

Answer 6

在 Java EE 服务器上，如果您的 URL 引用了不存在的“web 应用程序”，则会返回 400。那是“语法错误”吗？取决于语法错误的含义。我会说是的。

在英语中，句法规则规定了词类之间的某些关系。例如，“Bob marries Mary”在语法上是正确的，因为它遵循模式 {Noun + Verb + Noun}。然而 “鲍勃婚姻玛丽”在语法上是不正确的，{Noun + Noun + Noun}。

简单 URL 的语法是 { protocol + : + // + server + : + port }。据此，“http://www.google.com:80”在语法上是正确的。

但是“abc://www.google.com:80”呢？它似乎遵循完全相同的模式。但真的 这是一个语法错误。为什么？因为 'abc' 不是 DEFINED 协议。

关键是确定我们是否有 400 的情况需要的不仅仅是解析字符、空格和分隔符。它还必须识别什么是有效的“词性”。

Answer 7

这很难。

我认为我们应该；

1. 仅当客户端有权更改请求、标头或正文时返回 4xx 错误，这将导致请求以相同的意图成功。

2. 在未发生预期突变时返回错误范围代码，即未发生 DELETE 或 PUT 未更改任何内容。但是，POST 更有趣，因为规范说它应该用于在新位置创建资源，或者只处理有效负载。

使用 Vish 回答中的示例，如果请求打算将员工 Priya 添加到营销部门但未找到 Priya 或她的帐户已存档，那么这是一个应用程序错误。

请求运行良好，符合您的应用程序规则，客户端一切正常，ETag 匹配等等。

因为我们使用的是 HTTP，所以我们必须根据请求对资源状态的影响做出响应。这取决于您的 API 设计。

也许这是你设计的。

PUT { updated members list } /marketing/members

返回成功代码将表明资源的“替换”有效；对资源的 GET 会反映您的更改，但不会。

所以现在您必须选择一个合适的否定 HTTP 代码，这是棘手的部分，因为这些代码主要用于 HTTP 协议，而不是您的应用程序。

看了官方的HTTP代码，这两个看起来很合适。

409（冲突）状态码表示由于与目标资源的当前状态冲突，请求无法完成。此代码用于用户可能能够解决冲突并重新提交请求的情况。服务器应该生成一个有效载荷，其中包含足够的信息让用户识别冲突的来源。

和

500（内部服务器错误）状态代码表示服务器遇到了阻止其完成请求的意外情况。

虽然我们传统上认为 500 就像一个未处理的异常：-/

我不认为发明自己的状态码是不合理的，只要它始终如一地应用和设计。

这种设计比较容易处理。

PUT { membership add command } /accounts/groups/memberships/instructions/1739119

然后您可以设计您的 API 以始终成功创建指令，它返回 201 Created 和一个 Location 标头，并且该指令的任何问题都包含在该新指令中资源。

POST 更像是最后一次 PUT 到新位置。 POST 允许对消息进行任何类型的服务器处理，这会打开类似“操作成功失败”之类的设计。

您可能已经编写了一个执行此操作的 API，即网站。您 POST 付款表单，但由于信用卡号码错误而被成功拒绝。

对于 POST，是否返回 200 或 201 以及拒绝消息取决于是否创建了新资源并且是否可以在其他位置进行 GET。

综上所述，我倾向于设计需要更少 PUT 的 API，也许只是更新数据字段，以及调用规则和处理的操作和内容，或者只是有更高的预期失败机会，可以设计为发布说明。

Answer 8

就我而言：

我收到 400 个错误请求，因为我错误地设置了 content-type。我更改了内容类型，然后能够成功获得响应。

之前（问题）：

ClientResponse response = Client.create().resource(requestUrl).queryParam("noOfDates", String.valueOf(limit))
                .header(SecurityConstants.AUTHORIZATION, formatedToken).
header("Content-Type", "\"application/json\"").get(ClientResponse.class);

之后（固定）：

ClientResponse response = Client.create().resource(requestUrl).queryParam("noOfDates", String.valueOf(limit))
                .header(SecurityConstants.AUTHORIZATION, formatedToken).
header("Content-Type", "\"application/x-www-form-urlencoded\"").get(ClientResponse.class);