463

我在想 412（前提条件失败）但可能有更好的标准？

4

9 回答 9

454

根据规范，状态 422 似乎最合适。

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

他们指出格式错误的 xml 是错误语法的一个示例（要求 400）。格式错误的查询字符串似乎与此类似，因此 400 似乎不适合缺少参数的格式良好的查询字符串。

更新@DavidV 正确指出该规范适用于 WebDAV，而不是核心 HTTP。但是一些流行的非 WebDAV API 无论如何都在使用 422，因为缺少更好的状态码（见这个）。

于 2012-04-25T20:14:25.410 回答
219

我不确定是否有一套标准，但我会使用400 Bad Request，最新的 HTTP 规范（从 2014 年开始）记录如下：

6.5.1. 400 错误请求

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

于 2010-06-16T03:32:06.927 回答
36

.NET 中的WCF API在使用webHttpBindingHTTP 404时通过返回“未找到端点”错误来处理丢失的参数。

如果您考虑您的 Web 服务方法名称及其参数签名，这404 Not Found可能是有意义的。也就是说，如果您公开了一个 Web 服务方法LoginUser(string, string)并且您请求LoginUser(string)，则找不到后者。

基本上，这意味着您正在调用的 Web 服务方法以及您指定的参数签名无法找到。

10.4.5 404 未找到

服务器未找到任何与请求 URI 匹配的内容。没有说明这种情况是暂时的还是永久性的。

400 Bad Request正如Gert 所建议的， 仍然是有效的响应代码，但我认为它通常用于指示较低级别的问题。它很容易被解释为格式错误的 HTTP 请求，可能是 HTTP 标头丢失或无效，或类似情况。

10.4.1 400 错误请求

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

于 2010-06-16T03:55:13.023 回答
16

您可以发送 400 Bad Request 代码。它是更通用的 4xx 状态代码之一，因此您可以使用它来表示您的意图：客户端发送的请求缺少您的应用程序正确处理它所需的信息/参数。

于 2010-06-16T03:32:05.800 回答
6

如果所需参数中的某些内容与 API 端点所需的内容不匹配（例如密码太短），我通常会选择 422（不可处理实体），但对于缺少的参数，我会选择 406（不可接受）。

于 2014-03-06T09:32:31.773 回答
5

在我们的一个 API 项目中，我们决定为某个请求设置 409 状态，因为缺少参数，我们无法以 100% 完全填充它。

HTTP 状态代码“409 冲突”对我们来说是一个很好的尝试，因为它的定义要求包含足够的信息让用户识别冲突的来源。

参考：w3.org/Protocols/

因此，在 400 或 404 等其他响应中，我们选择了 409 来强制查看请求中的一些注释，这有助于建立一个新的和正确的请求。

无论如何，我们的案例都是特殊的，因为如果请求不完全正确，我们需要在前夕发送一些数据，并且我们需要强制客户端查看消息并了解请求中的错误。

In general if we have only some missing parameter we go for a 400 and an array of missing parameter. But when we need to send some more information, like a particular case message and we want to be more sure the client will take care of it we send a 409

于 2015-01-08T14:06:39.633 回答
3

可以说404 Not Found应该使用 a ，因为找不到指定的资源。

于 2012-01-17T14:44:00.370 回答
3

对于那些感兴趣的人，Spring MVC（至少 3.x）在这种情况下返回 400，这对我来说似乎是错误的。

我测试了几个 Google URL (accounts.google.com) 并删除了必需的参数，在这种情况下它们通常返回 404。

我会复制谷歌。

于 2012-05-19T21:01:22.077 回答
0

我经常使用 403 Forbidden 错误。理由是请求被理解，但我不会按要求去做（因为事情是错误的）。响应实体解释了问题所在，因此如果响应是 HTML 页面，则错误消息在页面中。如果是 JSON 或 XML 响应，则错误信息就在其中。

来自rfc2616：

10.4.4 403 禁止

服务器理解请求，但拒绝执行。
授权将无济于事，并且不应重复请求。
如果请求方法不是 HEAD 并且服务器希望
公开请求未完成的原因，它应该在实体中描述拒绝的原因。如果服务器不希望向客户端提供此信息，则可以使用状态代码 404
（未找到）来代替。

于 2012-02-23T22:36:36.370 回答