首页 文章

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

提问于
浏览
322

每当我在基于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 回答

  • 12

    如果“验证失败”意味着请求中存在某些客户端错误,则使用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,因此它知道要发送什么类型的凭据以及采用何种格式 . [...]

  • 21

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

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

  • 249

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

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

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

  • 74

    这里是:

    rfc2616#section-10.4.1 - 400 Bad Request

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

    rfc7231#section-6.5.1 - 6.5.1. 400 Bad Request

    400(错误请求)状态代码指示服务器由于被认为是客户端错误(例如,格式错误的请求语法,无效的请求消息成帧或欺骗性请求路由)而不能或不会处理该请求 .

    指畸形(不良)的案件!

    rfc4918 - 11.2. 422 Unprocessable Entity

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

    Conclusion

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

    422 符合最佳对象验证错误(正是我的建议:)
    至于 semantically erroneous - 想想像"This username already exists"验证 .

    400错误地用于对象验证

  • 7

    我会说在技术上它可能不是HTTP失败,因为资源(可能)有效地指定,用户已经过身份验证,并且没有操作失败(但是,即使规范确实包括一些保留代码,如402 Payment Required,严格来说也不是HTTP相关的,尽管可能建议在协议级别使用,以便任何设备都可以识别条件) .

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

    <status> <code> 4 </ code> <message>日期范围无效</ message> </ status>

  • 1

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

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

  • 0

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

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

相关问题