REST API服务针对验证失败返回什么合适的HTTP状态代码？

每当我在基于Django / Piston的REST API应用程序中遇到验证失败时，我当前都会返回401未经授权。看过HTTP状态代码注册表后， 我不相信这是验证失败的合适代码，大家都建议什么？

• 400错误的要求
• 401未经授权
• 403禁止
• 405方法不允许
• 406不可接受
• 412前提条件失败
• 417期望失败
• 422无法处理的实体
• 424依赖失败

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

如果“验证失败”表示请求中存在某些客户端错误，请使用HTTP 400（错误请求）。例如，如果URI应该具有ISO-8601日期，而您发现它的格式错误或引用的日期是2月31日，则您将返回HTTP400。如果您希望实体主体中格式正确的XML，则返回同上它无法解析。

（1/2016）：在过去的五年中，WebDAV更为具体的HTTP 422（不可处理实体）已成为HTTP 400的非常合理的替代品。例如，请参见在JSON API中的使用。但是请注意，HTTP 422 尚未将其纳入HTTP 1.1，RFC-7231中。

Richardson和Ruby的RESTful Web服务包含有关何时使用各种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＃section-10.4.1-400错误的请求

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

rfc7231＃section6.5.1-6.5.1。400错误的要求

400（错误请求）状态码表示服务器由于某些原因（例如格式错误的请求语法，无效的请求消息框架或欺骗性的请求路由）而被视为无法处理或无法处理该请求。

指格式错误（格式不正确）的情况！

rfc4918-11.2。422无法处理的实体

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

结论

经验法则：[_] 00涵盖最常见的情况以及指定代码未涵盖的情况。

422适合最佳对象验证错误（精确地是我的建议：）
至于语义上的错误-考虑类似“此用户名已存在”验证之类的事情。

400错误地用于对象验证

从技术上讲，我认为这可能不是HTTP失败，因为（大概）有效地指定了资源，对用户进行了身份验证，并且没有操作失败（但是，即使规范中确实包含一些保留的代码，例如402 Payment Required Required，但不是）严格来说，两者都是HTTP相关的，尽管建议在协议级别使用HTTP，以便任何设备都可以识别该情况。

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

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

RFC 2616中提供了有关这些错误的语义的更多信息，该文档记录了HTTP 1.1。

就个人而言，我可能会使用400 Bad Request，但这只是我的个人观点，没有任何事实依据。

您所说的“验证失败”到底是什么意思？您在验证什么？您是否在指类似语法错误的内容（例如XML格式不正确）？

如果是这样，我想说400 Bad Request可能是正确的事情，但是如果不知道它是什么，那么您就无法确定。