Xml REST-何时使用400（“错误请求”）

我有这样一个资源sales/customers/{customerno}。如果客户机向该资源发送PUT请求，如果实体体中的xml不是有效的xml，我将返回400-Bad请求。但是，如果xml是有效的，但xml的内容是无效的，该怎么办呢。例如，假设客户试图更新客户的邮政编码，但提供的邮政编码无效。在这种情况下，返回400-错误请求是正确的，还是我应该使用的另一个http代码？

来自：

400错误请求： 由于语法错误，无法满足请求

在本例中，您的客户机向您发送了一个包含无效邮政编码的XML有效负载，这是一种无效语法形式；因此，在这种情况下，发送400错误请求是返回正确的错误代码

此外，维基百科还引用了这方面的资源。从本文档中，您可以找到以下信息：

服务器可能会拒绝有问题的请求（即使 它们由格式良好的XML（XML）和400（坏的 请求）状态代码和解释请求的可选响应正文 问题

由于您的请求格式正确（XML不错，它只包含语义不正确的信息），因此您可以拒绝状态代码为400的内容。单词

*may*

表示还有其他选择

虽然您可能会尝试使用状态代码422，但在这种情况下这是不正确的，因为无效的邮政编码不符合语义错误的标准。请看下面

来自维基百科：

422不可处理实体（WebDAV；RFC 4918）： 请求格式正确，但由于语义错误而无法遵循

此外，以下是一些：

• 语法错误发生在输入代码的解析过程中，由语法错误的语句引起。典型的错误可能是输入中的非法字符、缺少运算符、一行中的两个运算符、同一行中没有分号的两个语句、不平衡的括号、错误放置的保留字等

• 在代码被解析为语法正确后，在代码执行过程中会出现语义错误。这些与语句的构造方式无关，而是与它们的含义有关。诸如不正确的变量类型或大小、不存在变量、下标超出范围等都是语义错误

无效的邮政编码既不是语法错误，也不是语义错误；因此，排除状态代码422作为选项是合理的

---

要回答您的问题，状态代码400是合适的；但是，您也可以有其他选择。

找到的HTTP规范的修订版更新了措辞，试图避免400仅限于格式错误的请求的混淆

7.4.1。400错误请求

由于客户端的原因，服务器无法或将不会处理该请求 错误（例如语法错误）

---

其他的选择是？我发现这很有用，但我对结论有点困惑。我知道计算机科学对“语义”有一个不同于一般用法的定义。在计算机科学之外，在此上下文中，无效的邮政编码确实可以称为语义错误。我想你是对的，RFC的意思是计算机科学意义上的，但是这样的错误有多大用处呢？事实上，这怎么可能是一个客户端错误呢？我不明白422的状态。如果邮政编码123456无效，这是语义（逻辑）错误，不是吗？这样，我们应该使用422状态-澄清的是“语义”定义的最后一句话。当他们说语义错误时，他们指的是不正确的变量大小或类型、不存在的变量、超出范围的下标等。无效的邮政编码似乎是数据问题，而不是数据类型或数据大小问题、数组下标超出范围等。实际上，我可以想到一个例子。如果您将数据类型的大小调整为仅取5位，并将其设为6位，那么我确实认为您可以使用状态代码422，但我认为这只是超出数据类型长度的副作用，而不是因为实际数据无效。我仍然可以给出一个不超过任何变量限制的无效的5位邮政编码，在这种情况下，我认为我们不能证明状态码422是正确的。希望这能有所帮助。400代码是否也包括用户不是资源所有者的有效负载中的id？@Elisabeth不确定我是否完全理解您的场景，但我认为答案是肯定的。该场景是一个具有属于另一个用户的外键id的有效负载。删除服务器上的这些id将删除其他用户的资源。那太糟糕了。@Elisabeth那么是的，我认为400适合告诉用户提交的请求不是合理的请求。在您的场景中，由于相关资源属于另一个所有者，403 Forbidden可能是一个更精确的状态代码。@Elisabeth我想我会在您的案例中使用403，因为它更具体——请求删除这些资源可能是客户端错误，但这是一个错误，因为它是被禁止的。这将提供更多信息。