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

Question

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

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

Answer 1

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

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

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

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

引用的规范适用于WebDAV,而不是HTTP标准规范. (12认同)
IMO 我会在查询字符串中的值不正确时使用它，而不是当存在额外值或缺失值时。IE。期待电子邮件，其值为“123123” (4认同)
@DavidV 你是对的，它适用于 WebDAV，但对于核心 HTTP 似乎没有更好的选择。[此博客](http://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm) 提到了使用 422 的流行 API。 (3认同)
这值得一读:https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm我也不会使用422来丢失参数.我认为`400`更合适. (3认同)
我倾向于将GET和POST参数视为URL路径的方法签名，因此404对我来说很有意义。在供公众使用的RESTful API中，谨慎地返回missing / extra参数。在URL的上下文中，查询字符串参数通常对于标识资源很重要，多余或缺少的参数表示不存在的资源，无需任何假设。当然，通过显式进行健壮性需要权衡取舍，而可选参数使资源可能同样容易受到静默错误的影响。然后就是可用性... (2认同)

Answer 2

Ger*_*der 168

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

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

"400 Bad Request"用于表示协议级问题,而不是语义错误.如果我们要劫持HTTP状态代码来指示应用程序级别(而不是协议级别)错误,那么为什么不一直使用`412`？ (63认同)
谷歌的OAuth 1.0实施同意这个答案.POST参数丢失或不受支持时会给出400响应:http://code.google.com/apis/accounts/docs/OAuth_ref.html (33认同)
@DarrelMiller是对的([直接链接](https://tools.ietf.org/html/rfc7231#section-6.5.1)):*"400(错误请求)状态代码表明服务器不能或不会由于被认为是客户端错误的事情(例如,格式错误的请求语法,无效的请求消息框架或欺骗性请求路由)而处理请求."*取决于语义和可扩展性期望(有一天可以发布一个请求没有参数？)然后在标准HTTP中只有400和404似乎合适.否则,为您的API发明一个新代码,但不要重载语义. (9认同)
@MattZukowski 400是应用程序级别的状态代码.如果你看一下RFC 7231草案版本中的重写,你会看到.不幸的是,最新版本的措辞并不是那么清楚,因为最新变化的作者也发明了422. (5认同)
@matt-zukowski：“412：在服务器上测试时，一个或多个请求标头字段中给出的前提条件评估为假。” 来自 [RFC2616](http://www.ietf.org/rfc/rfc2616.txt) - 如果是 POST，则参数位于请求正文中，而不是请求标头字段中。从技术上讲，GET 方法在请求头中发送它的参数，但我宁愿有一些一致性？ (2认同)

Answer 3

Dan*_*llo 30

当使用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错误请求

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

这种解释似乎有点牵强，它表达的是 RPC 而不是 REST pov。URI 是标识符，它存在并已被找到。正文中发送的内容不是资源标识符的一部分。422更合适。 (2认同)

Answer 4

gab*_*lem 8

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

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

参考:w3.org/Protocols/

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

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

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

这是完全错误的。409 用于并发问题，因为@MaximeGélinas 指出资源已经存在且不允许重复的情况。 (5认同)

Answer 5

Bol*_*ock 7

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

Answer 6

Ela*_*dar 5

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

好吧,406 Unacceptable与Accept标头一起使用(如果服务器无法发送客户端会理解的响应)."请求标识的资源只能生成响应实体,这些响应实体的内容特征根据请求中发送的接受标头不可接受." .我坚持使用422,因为目前的规格没有"正确"的选择: - / (7认同)
为此使用 406 是错误的。406 代码并不意味着*请求*不可接受；而是意味着该请求不被接受。这意味着您无法满足请求，因为根据在请求中发送的 Accept 标头，您能够提供的响应是 *客户端* 认为不可接受的响应。（例如，请求包含“Accept-Language：de”，表示它只接受德语响应，但您的服务器可用的请求文档的唯一版本是英语或法语。）用它来指示缺失根据规范中的定义，请求中的参数不正确。 (2认同)

归档时间：	15 年，7 月前
查看次数：	200642 次
最近记录：	6 年，2 月前