Api 将HTTP状态代码设置为错误输入

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

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

使用

500

更像是服务器问题
使用带有警告/错误响应文本的

200

是错误的（允许缓存，但一切都不正常）
使用

204

但不返回任何内容可能是好的（但得到了很好的支持？
如果请求的路径（脚本）可用且位置正确，则使用

404

是错误的

以4（4xx）开头的代码用于客户端错误。也许400（错误请求）适用于这种情况？中的定义是：

---

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

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

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

422不可处理的实体

，其中说明：

422（不可处理实体）状态代码意味着服务器理解请求实体的内容类型（因此415（不支持的媒体类型）状态代码不合适），并且请求实体的语法正确（因此400（坏请求）状态代码不合适），但无法处理包含的指令。例如，如果XML请求体包含格式正确（即语法正确）但语义错误的XML指令，则可能会出现这种错误情况

---

来源：

409冲突

可能是可接受的解决方案

根据：

由于与资源的当前状态冲突，无法完成请求。只有在预期用户可能能够解决冲突并重新提交请求的情况下，才允许使用此代码。响应主体应包含足够的信息，以便用户识别冲突的来源。理想情况下，响应实体将包括足够的信息，供用户或用户代理修复问题；然而，这可能是不可能的，也不是必须的

本文件继续给出一个示例：

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

---

在我的例子中，我想通过API将一个必须是唯一的字符串放入数据库。在将其添加到数据库之前，我要检查它是否已经在数据库中

如果是，我将返回

“错误：字符串已在数据库中”，409

---

我相信这就是OP想要的：一个适用于数据不符合服务器标准时的错误代码。

根据以下场景

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

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

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

这种描述不太符合实际情况；但是，如果您查看HTTP/1.1协议中定义的核心HTTP状态代码列表，它可能是您的最佳选择

然而，最近，我的开发团队有人[向我]指出，流行的API开始使用HTTP扩展来更精细地报告错误。具体来说，许多API，如Twitter和Recurly，都使用WebDAV HTTP扩展中定义的状态代码“422 Unprocessable Entity”。HTTP状态代码422表示：

422（不可处理实体）状态代码表示服务器 理解请求实体的内容类型（因此是415） （不支持的媒体类型）状态代码不正确），以及语法 请求实体的状态代码正确（因此为400（错误请求）状态代码 是不合适的），但无法处理包含的 说明书例如，如果XML 请求主体包含格式良好的（即语法正确的），但 语义错误的XML指令

---

回到上面的密码示例，这个422状态代码感觉更合适。服务器理解您试图做什么；它了解您提交的数据；它只是不允许处理该数据。

400错误请求

并不坏，但通常应保留用于格式错误的语法。OP似乎更关心语法格式良好但值无效的情况。Plus 400是一个相当常见的“噢，该死，有些东西不对”响应代码，您可能希望将其与错误输入的特定情况区分开来。请注意，RFC 7231中更新了措辞，并且“由于语法错误，服务器无法理解请求”更新为“由于被认为是客户端错误（例如，格式错误的请求语法，i