每当我在基于Django / Piston的REST API应用程序中遇到验证失败时,我目前正在返回401 Unauthorized . 看了HTTP Status Code Registry我'm not convinced that this is an appropriate code for a validation failure, what do y'所有推荐?
-
400错误请求
-
401未经授权
-
403禁止
-
405方法不允许
-
406不可接受
-
412前提条件失败
-
417期望失败
-
422不可处理的实体
-
424依赖关系失败
上述 Update :"Validation failure"表示应用程序级数据验证失败,即错误指定日期时间,虚假电子邮件地址等 .
7 回答
如果“验证失败”意味着请求中存在某些客户端错误,则使用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响应代码的非常有用的附录 . 他们说:
和:
来自RFC 4918(也记录在http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml):
数据库中的副本应为
409 CONFLICT
.我建议使用
422 UNPROCESSABLE ENTITY
进行验证错误 .我在这里给出了4xx代码的更长解释:http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/
这里是:
rfc2616#section-10.4.1 - 400 Bad Request
rfc7231#section-6.5.1 - 6.5.1. 400 Bad Request
指畸形(不良)的案件!
rfc4918 - 11.2. 422 Unprocessable Entity
Conclusion
经验法则:[_] 00涵盖指定代码未涵盖的最一般情况和案例 .
422 符合最佳对象验证错误(正是我的建议:)
至于 semantically erroneous - 想想像"This username already exists"验证 .
400错误地用于对象验证
我会说在技术上它可能不是HTTP失败,因为资源(可能)有效地指定,用户已经过身份验证,并且没有操作失败(但是,即使规范确实包括一些保留代码,如402 Payment Required,严格来说也不是HTTP相关的,尽管可能建议在协议级别使用,以便任何设备都可以识别条件) .
如果确实如此,我会在响应中添加一个状态字段,其中包含应用程序错误,例如
<status> <code> 4 </ code> <message>日期范围无效</ message> </ status>
在RFC 2616中有关于这些错误语义的更多信息,它们记录了HTTP 1.1 .
就个人而言,我可能会使用
400 Bad Request
,但这只是我的个人意见而没有任何事实支持 .“验证失败”究竟是什么意思?你在验证什么?你指的是语法错误(例如格式错误的XML)吗?
如果是这种情况,我会说400 Bad Request可能是正确的,但不知道它是什么“你正在验证”,这是不可能的 .