REST API服务为验证失败返回的适当HTTP状态代码是什么?

时间:2009-12-24 22:34:52

标签: validation rest http-status-codes

每当我在基于Django / Piston的REST API应用程序中遇到验证失败时,我正在返回401 Unauthorized。 看了HTTP Status Code Registry 我不相信这是验证失败的合适代码,你们都推荐什么?

  • 400 Bad Request
  • 401 Unauthorized
  • 403 Forbidden
  • 405方法不允许
  • 406不可接受
  • 412 Precondition Failed
  • 417期望失败
  • 422 Unprocessable Entity
  • 424依赖关系失败

更新:上述“验证失败”表示应用程序级数据验证失败,即错误指定日期时间,虚假电子邮件地址等。

7 个答案:

答案 0 :(得分:260)

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

(1/2016):在过去的五年中,WebDAV更具体的HTTP 422(不可处理的实体)已成为HTTP 400的一个非常合理的替代方案。例如,请参阅JSON API中的用法。但请注意,HTTP 422的使其成为HTTP 1.1,RFC-7231

Richardson和Ruby的RESTful Web Services包含了关于何时使用各种HTTP响应代码的非常有用的附录。他们说:

  

400(“错误请求”)
  重要性:高   这是通用客户端错误状态,在没有其他4xx错误代码适用时使用。它通常在客户端提交表示时使用   PUT或POST请求,表示格式正确,但没有   任何意义。 (第381页)

  

401(“未经授权”)
  重要性:高   客户端尝试在受保护的资源上运行,但未提供正确的身份验证凭据。它可能提供了错误的凭据,或者根本没有。   凭证可以是用户名和密码,API密钥或认证   令牌 - 无论有问题的服务是什么。客户经常这样做   请求URI并接受401只是为了知道要发送什么类型的凭据   以什么格式。 [...]

答案 1 :(得分:80)

来自RFC 4918(并且还记录在http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml):

  

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

答案 2 :(得分:22)

数据库中的副本应为409 CONFLICT

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

我在这里给出了4xx代码的更长解释:http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

答案 3 :(得分:13)

这是:

rfc2616#section-10.4.1 - 400错误请求

  

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

rfc7231#section-6.5.1 - 6.5.1。 400错误请求

  

400(错误请求)状态代码表示服务器不能    或者由于感知到的东西而不会处理请求   成为客户端错误 (例如,格式错误的请求语法,无效的请求消息框架或欺骗性请求路由)

指的是格式错误(不正确)的案例!

rfc4918 - 11.2。 422不可处理的实体

  

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

<强>结论

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

422 符合最佳对象验证错误(正是我的推荐:)
至于语义错误 - 想想“此用户名已存在”验证。

400错误地用于对象验证

答案 4 :(得分:7)

我会说技术上它可能不是HTTP失败,因为资源(可能)有效地指定,用户经过身份验证,并且没有操作失败(但是即使规范也包含一些保留代码,如402 Payment Required严格来说,它们与HTTP无关,但建议在协议级别使用,以便任何设备都能识别出这种情况。)

如果确实如此,我会在响应中添加一个状态字段,其中包含应用程序错误,例如

&lt; status&gt;&lt; code&gt; 4&lt; / code&gt;&lt; message&gt;日期范围无效&lt; / message&gt;&lt; / status&gt;

答案 5 :(得分:1)

RFC 2616中有关于这些错误的语义的更多信息,它们记录了HTTP 1.1。

就个人而言,我可能会使用400 Bad Request,但这只是我个人的意见而没有任何实际的支持。

答案 6 :(得分:0)

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

如果是这种情况,我会说400 Bad Request可能是正确的,但不知道它是什么“你正在验证”,这是不可能的。