什么是REST API服务返回validation失败的合适的HTTP状态码？
我目前正在返回401 Unauthorized，当我在基于Django / Piston的REST API应用程序中遇到validation失败时。 看过HTTP状态代码registry我不相信这是一个validation失败的适当的代码，你们都推荐什么？
- 400错误的请求
- 401未经授权
- 403禁止
- 405方法不允许
- 406不可接受
- 412先决条件失败
- 417期望失败
- 422不可处理的实体
- 424失败的依赖
更新 ：上面的“validation失败”是指应用程序级数据validation失败，即错误地指定了date时间，伪造的电子邮件地址等。
如果“validation失败”表示请求中存在某些客户端错误，则使用HTTP 400（错误请求）。 例如，如果URI应该有一个ISO-8601的date，并且你发现它的格式是错误的，或者指的是2月31日，那么你会返回一个HTTP 400.如果你期望在一个实体正确的formsXML和它不能parsing。
（1/2016）：在过去的五年中， WebDAV更具体的HTTP 422（不可处理的实体）已经成为HTTP 400的一个非常合理的替代scheme。例如，请参阅JSON API中的使用。 但请注意，HTTP 422还没有将其转换为HTTP 1.1， RFC-7231 。
Richardson和Ruby的RESTful Web服务在何时使用各种HTTP响应代码中包含了非常有用的附录。 他们说：
400（“坏请求”）
重要性：高。
这是通用的客户端错误状态，在没有其他4xx错误代码是合适的时使用。 当客户端提交一个PUT或POST请求的表示，并且表示格式正确时，通常使用它，但是没有任何意义。 （第381页）
和：
401（“未经授权”）
重要性：高。
客户端尝试在受保护的资源上运行而不提供适当的身份validation凭证。 它可能提供了错误的凭据，或根本没有。 凭据可以是用户名和密码，API密钥或authentication令牌，不pipe有问题的服务如何。 客户端通常会请求一个URI并接受一个401，这样它就知道要发送什么样的凭证，以什么格式。 […]
从RFC 4918（也logging在http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml ）：
422（不可处理的实体）状态码意味着服务器理解请求实体的内容types（因此415（不支持的媒体types）状态码是不合适的），并且请求实体的语法是正确的（因此400（错误的请求）状态码不合适），但无法处理包含的说明。 例如，如果XML请求主体包含格式正确（即，语法正确），但语义错误的XML指令，则可能出现此错误情况。
数据库中的副本应该是409 CONFLICT 。
我build议使用422 UNPROCESSABLE ENTITY来validation错误。
我在这里给出了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错误的请求
400（错误请求）状态码指示服务器由于被认为是客户端错误（例如格式错误的请求语法，无效请求消息成帧或欺骗性请求路由）而不能或不会处理该请求。
指格式不正确（不合格）的情况！
rfc4918 – 11.2。 422不可处理的实体
422（不可处理实体）状态码表示服务器
理解请求实体的内容types（因此415（不支持的媒体types）状态码是不合适的），并且请求实体的语法是正确的 （因此400（错误请求）状态码是不适当的），但是不能处理包含的说明。 例如，如果XML请求主体包含格式正确（即，语法正确），但语义错误的 XML指令，则可能出现此错误情况。
结论
经验法则：[_] 00涵盖了未被指定代码覆盖的最一般的案例和案例。
422适合最好的对象validation错误（正是我的build议:)
至于语义上的错误 –想想像“这个用户名已经存在”的validation。
400不正确地用于对象validation
从技术上讲，这可能不是一个HTTP失败，因为资源（大概）被有效地指定，用户被authentication，并且没有操作失败（然而，即使规范确实包括一些保留的代码，如402 Payment Required，严格来说，HTTP也是相关的，尽pipe在协议层次上可能是明智的，这样任何设备都可以识别这种情况）。
如果实际上是这样，我会添加一个状态字段到应用程序错误的响应，如
<status> <code> 4 </ code> <message>date范围无效</ message> </ status>
在RFC 2616中有关于这些错误的语义的更多信息，这些信息logging了HTTP 1.1。
就个人而言，我可能会使用400 Bad Request ，但这仅仅是我个人的意见，没有任何事实支持。
“确认失败”是什么意思？ 你在validation什么？ 你是否指的是一个语法错误（如格式不正确的XML）？
如果是这样的话，我会说400错误请求可能是正确的，但是不知道你是什么“validation”，这是不可能的。
