400对422对数据发布的响应

Question

{
    "account_number": 45645511,
    "upc": "00490000486",
    "price": 1.00,
    "tax": 0.08
}

如果客户端发送给我“sales_tax”（而不是预期的“tax”），我应该返回什么。目前，我正在退回400英镑。但是，我开始质疑自己。我真的应该还422吗？我的意思是，它是JSON（它是受支持的），它是有效的JSON，它只是不包含所有必需的字段。

Answer 1

400错误请求现在似乎是您用例的最佳HTTP/1.1状态代码。

在您提出问题（以及我最初的回答）时，RFC7231还不是一件事；当时我反对400错误请求，因为RFC2616说（强调了我的）：

由于语法错误，服务器无法理解请求。

400（Bad Request）状态代码指示服务器由于被认为是客户端错误（例如，错误的请求语法、无效的请求消息帧或欺骗性的请求路由）而不能或不会处理请求。

但是，在重新措辞之前（或者如果您想对RFC 7231只是当前建议的标准提出质疑），422 Unprocessable entity对于您的用例来说似乎并不是一个不正确的HTTP状态代码，因为正如RFC 4918的导言所说：

虽然HTTP/1.1提供的状态代码足以描述WebDAV方法遇到的大多数错误情况，但有些错误并不完全属于现有的类别。本规范定义了为WebDAV方法开发的额外状态代码（第11节）

而422的说明是：

422（不可处理的实体）状态代码意味着服务器理解请求实体的内容类型（因此415（不支持的媒体类型）状态代码是不合适的），并且请求实体的语法是正确的（因此400（错误请求）状态代码是不合适的），但是无法处理包含的指令。

（注意语法的引用；我怀疑7231也部分地过时了4918）

（将“XML”替换为“JSON”，我想我们可以同意这是您的情况）

现在，有些人会反对RFC4918是关于“Web分布式创作和版本控制（WebDAV）的HTTP扩展”，并且您（大概）没有做任何涉及WebDAV的事情，因此不应该使用它的东西。

在使用原始标准中的错误代码和扩展中的错误代码之间进行选择，前者显式地不覆盖这种情况，后者精确地描述了这种情况，我会选择后者。

此外，RFC 4918第21.4节提到了IANA超文本传输协议(HTTP)状态代码注册表，其中可以找到422。

我建议HTTP客户端或服务器使用该注册表中的任何状态代码是完全合理的，只要它们正确地这样做。

但是在HTTP/1.1中，RFC 7231具有牵引力，因此只需使用400 Bad request！