[英]What HTTP status response code should I use if the request is missing a required parameter?
我在想 412（前提条件失败）但可能有更好的标准？
根据规范，状态 422 似乎最合适。
422（Unprocessable Entity）状态码意味着服务器理解请求实体的内容类型（因此 415（Unsupported Media Type）状态码是不合适的），并且请求实体的语法是正确的（因此是 400（Bad Request） ) 状态码不合适）但无法处理包含的指令。 例如，如果 XML 请求正文包含格式正确（即语法正确）但语义错误的 XML 指令，则可能会出现这种错误情况。
他们指出格式错误的 xml 是错误语法的一个示例（要求 400）。 格式错误的查询字符串似乎与此类似，因此 400 似乎不适合缺少参数的格式良好的查询字符串。
注意：由于上述 RFC 是关于 WebDAV 的，因此可能会产生一种误解，即 422 和其他一些内容只能在 WebDAV 的上下文中使用，并且在 WebDAV 之外使用它们是“非标准的”。 但这仅意味着这些状态代码是在本 RFC 的上下文中引入的。 事实上，这些定义的措辞是经过精心挑选的，并非特定于 WebDAV。
我不确定是否有一套标准，但我会使用400 Bad Request ，最新的 HTTP 规范（从 2014 年开始）记录如下：
6.5.1. 400 错误请求
400 (Bad Request) 状态码表示服务器不能或不会处理请求，因为某些东西被认为是客户端错误（例如，格式错误的请求语法、无效的请求消息帧或欺骗性请求路由）。
使用webHttpBinding时，.NET 中的WCF API通过返回HTTP 404 “未找到端点”错误来处理丢失的参数。
如果您将 Web 服务方法名称连同其参数签名一起考虑，则404 Not Found可能是有意义的。 也就是说，如果您公开 Web 服务方法LoginUser(string, string)并请求LoginUser(string) ，则找不到后者。
基本上，这意味着您正在调用的 Web 服务方法以及您指定的参数签名无法找到。
10.4.5 404 未找到
服务器未找到任何与请求 URI 匹配的内容。 没有说明这种情况是暂时的还是永久性的。
正如Gert 所建议的， 400 Bad Request仍然是有效的响应代码，但我认为它通常用于指示较低级别的问题。 它很容易被解释为格式错误的 HTTP 请求，可能是 HTTP 标头丢失或无效，或类似情况。
10.4.1 400 错误请求
由于语法错误，服务器无法理解该请求。 客户端不应该在没有修改的情况下重复请求。
您可以发送 400 Bad Request 代码。 它是更通用的 4xx 状态代码之一，因此您可以使用它来表示您的意图：客户端发送的请求缺少您的应用程序正确处理它所需的信息/参数。
如果所需参数中的某些内容与 API 端点所需的内容不匹配（例如密码太短），我通常会选择 422（不可处理实体），但对于缺少的参数，我会选择 406（不可接受）。
在我们的一个 API 项目中，我们决定为某个请求设置 409 状态，因为缺少参数，我们无法以 100% 完全填充它。
HTTP 状态代码“409 冲突”对我们来说是一个很好的尝试，因为它的定义要求包含足够的信息让用户识别冲突的来源。
因此，在 400 或 404 等其他响应中，我们选择了 409 来强制查看请求中的一些注释，这有助于设置新的正确请求。
无论如何，我们的案例都是特殊的，因为如果请求不完全正确，我们需要在前夕发送一些数据，并且我们需要强制客户端查看消息并了解请求中的错误。
一般来说，如果我们只有一些缺失参数，我们会选择400和一组缺失参数。 但是当我们需要发送更多信息时，例如特定案例消息，并且我们希望更确定客户会处理它，我们发送 409
对于那些感兴趣的人，Spring MVC（至少 3.x）在这种情况下返回 400，这对我来说似乎是错误的。
我测试了几个 Google URL (accounts.google.com) 并删除了必需的参数，在这种情况下它们通常返回 404。
我会复制谷歌。
可以说应该使用404 Not Found ，因为找不到指定的资源。
返回404-表示找不到资源。
尝试编辑包含ID的网站的网址。 我尝试了一些：
所有人都返回404，imo，因为这些开发人员正在正确解释标准，这里的答案以及其他很多答案都没有！
我经常使用 403 Forbidden 错误。 理由是请求被理解，但我不会按要求去做（因为事情是错误的）。 响应实体解释了问题所在，因此如果响应是 HTML 页面，则错误消息在页面中。 如果是 JSON 或 XML 响应，则错误信息就在其中。
来自rfc2616 ：
10.4.4 403 禁止
服务器理解请求，但拒绝执行。
授权将无济于事，并且不应重复请求。
如果请求方法不是 HEAD 并且服务器希望
公开为什么请求没有被满足，它应该在实体中描述拒绝的原因。 如果服务器不希望向客户端提供此信息，则状态码 404
（未找到）可以代替。
我会选择403。
从RFC 2616-超文本传输协议-HTTP / 1.1
403禁止
服务器理解了该请求，但拒绝执行该请求。 授权将无济于事，不应重复该请求。 如果请求方法不是HEAD，并且服务器希望公开为什么未满足请求，则应在实体中描述拒绝原因。 如果服务器不希望将此信息提供给客户端，则可以改用状态代码404（未找到）。
您应在回复中说明失败的原因。 如果您不想这样做，请使用404。
如果请求丢失或错误的值（多选）路径参数，HTTP 状态响应码返回什么？
[英]What HTTP status response code return if the request is missing or wrong value(multiple choice) path parameter?
对于仅包含部分答案的 REST 响应，我应该使用什么 HTTP 状态代码？
[英]What HTTP status code should I use for a REST response that only contains part of the answer?
如果路径参数无效，我应该使用什么 HTTP 状态响应代码？
[英]What HTTP status response code should I use if a path param is not valid?
当请求缺少必需的cookie时，适当的HTTP状态代码是什么？
[英]What's the appropriate HTTP status code when the request is missing a required cookie?
如果资源未处于正确状态，我应该使用什么 HTTP 状态代码？
[英]What HTTP status code should I use if the resource is not in the right state?
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.
