Rest 400 vs 422对引用未知实体的帖子的响应

我正试图找出在不同的场景下，使用我正在使用的“rest-like”API返回的正确状态代码

这个例子借鉴了正文中的问题，但我的问题始终假定语法有效

假设我有一个端点，允许以JSON格式发布购买。看起来是这样的：

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

如果出现以下情况，相应的状态代码是什么：

• 帐号不存在
• 帐户已关闭或
• 识别的帐户类型不正确

这些都是阻止“处理”发生的业务层问题，然而，有一个场景涉及GET中的404

---

请注意，帐号不在URL中，所以404是否有误导性？

实际上，在这种情况下，404听起来不错。

让我们一次看一个。这些代码中的每一个都是向客户端发出的一个信号，表明服务器工作正常，在成功执行请求之前，必须更改请求中的某些内容

400（错误请求）状态代码表示服务器无法或将不会处理请求，原因是被认为是客户端错误（例如，格式错误的请求语法、无效的请求消息帧或欺骗性的请求路由）

400通常表示语法错误；作为用户，我应该在重试之前查看请求的结构

服务器未找到任何与请求URI匹配的内容。没有说明该情况是暂时的还是永久的。如果服务器通过一些内部可配置的机制知道旧资源永久不可用且没有转发地址，则应使用410（Gone）状态代码。当服务器不希望确切地揭示请求被拒绝的原因，或者当没有其他响应适用时，通常使用此状态代码

404是web服务器无法将url路径与任何内容匹配时使用的标准代码。作为客户机，我应该在重试之前查看请求的URL

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

422通常用于内容冲突。作为用户，我应该在重试之前查看请求的内容

现在，在您的情况下，帐号是一个标识号，但不包括在URL中。404会向用户发出URL错误的信号，而不是有效负载。换句话说，假设您的url为：

http://www.myservice.net/endpoint

404将向我指示在/endpoint处不存在服务，而不是没有帐号。无论我提交什么内容，服务器都不会处理我的请求。我应该做的修复是查找URL中的错误，而不是数据负载。因此，对我来说，422将为我指明正确的方向，除非你开始在URL中包含帐号

---

归根结底，这些都是设计首选项，只需确保与用户清楚地沟通即可。

我认为422在您的情况下是足够的，但如果它与API的其余部分一致，400也不错。当客户端出现错误时，使用400作为伞式错误代码是一种常见的约定，但是错误不符合特定的错误代码，或者您不想使用太多错误代码

---

如果邮政有效载荷出了问题，A 404肯定是错误的。

< P>如果您认为帐户是资源状态的一部分（虽然间接），那么您也可以考虑409，因为该状态与请求的语义冲突。

然而，422通过RubyonRails和Dropwizard越来越流行，在Dropwizard中，它被用来表示主体的非语法问题。这种增长趋势向使用API的开发人员发出了一个强烈的信号，即他们需要排除语法并关注主体。开发人员时间通常是您的客户将承担的最大成本，因此通过引导他们的开发人员的注意力，您将使他们感到高兴

---

所以409是一个可能的答案，虽然相当新颖，422是更传统的方法，尽管RoR和DropWizard显然都是新的，所以这些约定可以说变化很快

案例1：账号不存在。 这是404的标准案例

案例2：账户已关闭。 这与关闭帐户时保留帐户详细信息的逻辑有关。 如果您在账户关闭时没有保留账户详细信息，您可以提供404。 如果您在账户关闭后保留了账户详细信息，那么您必须对其进行标记（比如升起一些旗帜）（或者任何逻辑）。在这种情况下，状态代码400会显示一条正确的消息，说明其失败的原因，并可能进行补救

案例3：确定的账户类型不正确。

---

403，由于该账户未被授权完成任何购买，因此对我来说是有意义的。如果没有像授权账户这样的概念，400加上解释信息就可以了。但在这种情况下，我坚持使用403。

实际上，我在不同的场合都使用过这两种方法。409还具有作为原始RFC 2616 HTTP规范的一部分的好处。但趋势似乎是使用WebDAV的422代码。有任何答案对您有效吗？可能与Nope重复。这是关于业务层的问题，而不是语法（视图）