对于验证失败,RESTAPI服务返回的适当HTTP状态代码是什么?

如果“验证失败”意味着请求中存在一些客户端错误,则使用HTTP 400(错误请求)。例如,如果URI应该有一个ISO-8601日期,并且您发现它的格式错误或引用了2月31日,那么您将返回一个HTTP 400。如果您期望实体体中有格式良好的XML,但它无法解析,则同上。

(1/2016):过去五年 WebDAV 更具体的HTTP422(不可处理的实体)已经成为HTTP400的一个非常合理的替代方案。例如,请参见 JSON API . 但请注意,HTTP 422 不 把它变成了HTTP 1.1, RFC-7231 .

理查森和鲁比 RESTful Web Services 包含一个非常有用的附录,说明何时使用各种HTTP响应代码。他们说:

400(错误请求)
重要性:高。
这是一般的客户端错误状态,在没有其他4xx错误代码时使用。当客户提交一份声明时,通常使用 Put或Post请求,并且表示格式正确,但它不能 任何意义。(第381页)

还有:

401(未经授权)
重要性:高。
客户端试图在未提供正确身份验证凭据的情况下对受保护的资源进行操作。它可能提供了错误的凭证,或者根本没有。 凭据可以是用户名和密码、API密钥或身份验证 代币_,无论所讨论的服务是什么。客户通常会 请求一个URI并接受一个401,这样它就知道要发送哪种凭证了 以什么格式。[…]

来自RFC 4918(也记录在 http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml )以下内容:

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

数据库中的副本应为 409 CONFLICT .

我建议使用 422 UNPROCESSABLE ENTITY 验证错误。

我在这里对4xx代码作了更详细的解释: http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

这里是:

RFC2616第10.4.1节-400错误请求

服务器无法理解请求,因为 畸形的 语法 . 客户机不应在未经修改的情况下重复请求。

RFC7231第6.5.1-6.5.1节。400不良请求

400(错误请求)状态代码表示服务器无法 或者由于某些被感知到的东西而不处理请求 作为客户端错误 (例如,错误的请求语法、无效的请求消息帧或欺骗的请求路由) .

指畸形(不正常)病例!

RFC4918-11.2。422个不可加工实体

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

结论

经验法则:[]00涵盖了最一般的情况和指定代码未涵盖的情况。

422个 符合最佳对象验证错误(确切地说,我的建议是:)
至于 语义错误- 想想类似“这个用户名已经存在”的验证。

400不正确地用于对象验证

我会说,从技术上讲,这可能不是HTTP故障,因为资源(大概)被有效地指定了,用户已经过身份验证,并且没有操作故障(然而,即使规范也包括一些保留的代码,如402所需的付款,这些代码在严格意义上也与HTTP无关,尽管建议不要在协议级别上,使任何设备都能识别这种情况)。

如果实际是这样,我会在响应中添加一个状态字段,其中包含应用程序错误,比如

<状态><代码>4</code><消息>日期范围无效</message></status>

关于这些错误的语义,在 RFC 2616 ,其中记录了HTTP 1.1。

我个人可能会用 400 Bad Request 但这只是我个人的观点,没有任何事实支持。

“验证失败”究竟是什么意思?你在验证什么?您所指的是语法错误(例如,XML格式错误)之类的内容吗?

如果是这样的话,我会说400个错误的请求可能是正确的,但是如果不知道它是什么,你就无法“验证”它。