正确的HTTP状态代码输入错误

不报告200（一切正常）但输入错误时，最佳的HTTP响应代码是什么？

例如，您向服务器提交了一些数据，它将响应您的数据是错误的

使用500看起来更像是服务器问题
，200与警告/错误响应文本一起使用是不好的（允许缓存，并且一切都不好）
使用204并且什么也不返回，也许很好（但得到很好的支持？），如果请求的路径（脚本）可用并且
使用404错误，并且在适当的地方

制作我们的API时，我们也遇到了同样的问题。我们正在寻找与等效的HTTP状态代码InvalidArgumentException。阅读下面的源文章之后，我们最终使用422 Unprocessable Entity了以下状态：

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

来源：https : //www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm

以4（4xx）开头的代码用于客户端错误。也许400（错误请求）可能适合这种情况？http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html中的定义说：

“由于语法格式错误，服务器无法理解该请求。未经修改，客户端不应重复该请求。”

除了RFC规范， 您还可以看到它的实际效果。查看Twitter回复。

https://developer.twitter.com/zh-CN/docs/ads/general/guides/response-codes

409 Conflict 可能是一个可以接受的解决方案。

根据：https : //www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

由于与资源的当前状态存在冲突，因此无法完成请求。仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许使用此代码。响应主体应该包含足够的信息，以使用户能够识别冲突的根源。理想情况下，响应实体应包括足够的信息供用户或用户代理解决问题。但是，这可能是不可能的，也不是必需的。

该文档以一个示例继续：

响应PUT请求最有可能发生冲突。例如，如果正在使用版本控制，并且正在PUT的实体包括对资源的更改，该更改与先前（第三方）请求所做的更改冲突，则服务器可能会使用409响应来指示它无法完成请求。在这种情况下，响应实体可能会以响应Content-Type定义的格式包含两个版本之间差异的列表。

就我而言，我想通过API将一个必须唯一的字符串放入数据库。在将其添加到数据库之前，我正在检查它是否不在数据库中。

如果是，我将返回"Error: The string is already in the database", 409。

我相信这就是OP想要的：错误代码，适用于数据未通过服务器标准的情况。

根据以下情况，

假设有人使用正确格式的数据向服务器发出请求，但这些数据根本不是“好”数据。例如，假设有人将一个String值发布到期望一个String值的API端点；但是，该字符串的值包含被列入黑名单的数据（例如，防止人们使用“密码”作为其密码）。那么状态码可以是400或422？

到目前为止，我将返回“ 400错误请求”，根据w3.org，这意味着：

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

这种描述不太适合这种情况。但是，如果按照HTTP / 1.1协议中定义的核心HTTP状态代码列表进行操作，那可能是最好的选择。

但是，最近，我的开发团队中的某人向我指出，流行的API开始使用HTTP扩展来更详细地报告错误。具体来说，许多API（例如Twitter和Recurly）都使用状态代码“ 422无法处理的实体”，如WebDAV的HTTP扩展中所定义。HTTP状态码422指出：

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

从上面回到我们的密码示例，此422状态代码感觉更合适。服务器了解您要执行的操作；并且它了解您提交的数据；根本就不会处理这些数据。

404-找不到-可用于所请求的URI无效或所请求的资源（例如用户）不存在。