如果你正在验证数据，而数据不是，根据定义的规则，最好发送422(不可处理实体)，这样发送方就会明白他违反了约定的规则。

坏请求是语法错误。有些工具，如postman，会提前显示语法错误。

你说的“验证失败”到底是什么意思?你在验证什么?你指的是语法错误(比如格式错误的XML)吗?

如果是这样的话，我认为400个坏请求可能是正确的，但如果不知道你正在“验证”的是什么，就不可能说出来。

下面就是:

rfc2616#section-10.4.1 - 400错误请求

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

Rfc7231 #章节-6.5.1 -6.5.1。400错误请求

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

是指畸形(不完善)的情况!

Rfc4918 - 11.2。422不可处理实体

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415 (Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

结论

经验法则:[_]00涵盖了最常见的情况和指定代码未涵盖的情况。

422适合最好的对象验证错误(正是我的建议:) 至于语义错误——想想类似“这个用户名已经存在”的验证。

400被错误地用于对象验证

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

就我个人而言，我可能会使用400个坏请求，但这只是我个人的观点，没有任何事实支持。

如果“验证失败”意味着请求中有一些客户端错误，那么使用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服务包含了一个关于何时使用各种HTTP响应代码的非常有用的附录。他们说:

400(“错误请求”) 重要性:高。 这是一般的客户端错误状态，当没有其他合适的4xx错误代码时使用。它通常用于客户端提交一个表示和 PUT或POST请求，并且表示形式是正确的格式，但是它没有使 任何有意义的。(381页)

and:

401(“未经授权的”) 重要性:高。 客户端试图操作受保护的资源，但没有提供适当的身份验证凭据。它可能提供了错误的凭证，或者根本没有提供。 凭证可以是用户名和密码、API密钥或身份验证 令牌——不管服务期望什么。这对客户来说是很常见的 一个URI请求，并接受401，这样它就知道要发送什么样的凭据 以及什么样的格式。[…]

数据库中的副本应该是409冲突。

我建议使用422 UNPROCESSABLE ENTITY来处理验证错误。

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