如果请求缺少必需参数,我应该使用什么HTTP状态响应代码？

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

1> Kelvin..：

---

根据规范,状态422似乎最合适.

422(不可处理实体)状态代码表示服务器理解请求实体的内容类型(因此415(不支持的媒体类型)状态代码是不合适的),并且请求实体的语法是正确的(因此400(错误请求) )状态代码不合适)但无法处理包含的指令.例如,如果XML请求主体包含格式正确(即语法正确)但语义错误的XML指令,则可能发生此错误情况.

他们声称格式错误的xml是一个错误语法的例子(调用400).格式错误的查询字符串似乎与此类似,因此400似乎不适合缺少参数的格式良好的查询字符串.

UPDATE @DavidV正确地指出此规范适用于WebDAV,而不是核心HTTP.但是一些流行的非WebDAV API无论如何都使用422,因为缺少更好的状态代码(参见本文).

---

引用的规范适用于WebDAV,而不是HTTP标准规范.

---

这值得一读:https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm我也不会使用422来丢失参数.我认为`400`更合适.

---

我倾向于将GET和POST参数视为URL路径的方法签名，因此404对我来说很有意义。在供公众使用的RESTful API中，谨慎地返回missing / extra参数。在URL的上下文中，查询字符串参数通常对于标识资源很重要，多余或缺少的参数表示不存在的资源，无需任何假设。当然，通过显式进行健壮性需要权衡取舍，而可选参数使资源可能同样容易受到静默错误的影响。然后就是可用性...

2> Gert Grenand..：

---

我不确定是否有固定标准,但我会使用400 Bad Request:

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

---

"400 Bad Request"用于表示协议级问题,而不是语义错误.如果我们要劫持HTTP状态代码来指示应用程序级别(而不是协议级别)错误,那么为什么不一直使用`412`？

---

谷歌的OAuth 1.0实施同意这个答案.POST参数丢失或不受支持时会给出400响应:http://code.google.com/apis/accounts/docs/OAuth_ref.html

---

@DarrelMiller是对的([直接链接](https://tools.ietf.org/html/rfc7231#section-6.5.1)):*"400(错误请求)状态代码表明服务器不能或不会由于被认为是客户端错误的事情(例如,格式错误的请求语法,无效的请求消息框架或欺骗性请求路由)而处理请求."*取决于语义和可扩展性期望(有一天可以发布一个请求没有参数？)然后在标准HTTP中只有400和404似乎合适.否则,为您的API发明一个新代码,但不要重载语义.

---

@MattZukowski 400是应用程序级别的状态代码.如果你看一下RFC 7231草案版本中的重写,你会看到.不幸的是,最新版本的措辞并不是那么清楚,因为最新变化的作者也发明了422.

3> Daniel Vassa..：

---

当使用webHttpBinding时,.NET中的WCF API通过返回HTTP 404"未找到端点"错误来处理缺少的参数.

404 Not Found如果您将Web服务方法名称与其参数签名一起考虑,则可能有意义.也就是说,如果您公开Web服务方法LoginUser(string, string)并请求LoginUser(string),则找不到后者.

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

10.4.5 404未找到

服务器未找到与Request-URI匹配的任何内容.没有说明该病症是暂时的还是永久性的.

的400 Bad Request,因为格特建议,仍然是一个有效的响应代码,但我认为这是通常用于指示下级的问题.它可以很容易地被解释为格式错误的HTTP请求,可能缺少或无效的HTTP标头,或类似的.

10.4.1 400错误请求

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

4> gabrielem..：

---

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

HTTP状态代码"409 Conflict"对我们来说是一个很好的尝试,因为它的定义需要包含足够的信息以便用户识别冲突的来源.

参考:w3.org/Protocols/

因此,在400或404之类的其他响应中,我们选择409强制需要查看请求中的某些注释,这有助于设置新的正确请求.

我们的情况是特别的,因为如果请求不完全正确,我们需要发送一些数据,我们需要强制客户端查看消息并了解请求中的错误.

一般来说,如果我们只有一些缺失的参数,我们会得到一个400和一个缺失参数数组.但是当我们需要发送更多信息时,比如特定的案例信息,我们希望更加确定客户会处理它,我们发送409

5> BoltClock..：

---

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

6> Elad Meidar..：

---

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

---

好吧,406 Unacceptable与Accept标头一起使用(如果服务器无法发送客户端会理解的响应)."请求标识的资源只能生成响应实体,这些响应实体的内容特征根据请求中发送的接受标头不可接受." .我坚持使用422,因为目前的规格没有"正确"的选择: - /