Question

我正在尝试使用我正在处理的“类似休息”的API来确定在不同情况下返回的正确状态代码。

此示例借鉴了正文中的another question about syntax type个问题，但我的问题始终假设有效的语法。

假设我有一个允许以JSON格式购买POST的端点。它看起来像这样：

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

如果符合以下条件，适当的状态代码是什么：

帐号不存在
帐户已关闭或
确定的帐户不是正确的帐户

这些都是严格的业务层问题，阻止“处理”发生，但是，一个场景涉及GET中的某些内容将是404.

请注意，帐号不在网址中，因此404会误导？

Answer 1

让我们一次拿走这一个。这些代码中的每一个都是向客户端发出的信号，表明服务器正常运行，并且必须在请求中更改某些内容才能成功执行。

HTTP 400

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

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

HTTP 404

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

404是Web服务器无法匹配任何内容的URL路径时使用的标准代码。作为客户，我应该在再次尝试之前查看请求的网址。

HTTP 422

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

422通常用于内容违规。作为用户，我应该在再次尝试之前查看我的请求的内容。

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

http://www.myservice.net/endpoint

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

最终这些是设计偏好，只需确保您清楚地与用户沟通。

Answer 2

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

然而，422通过Ruby on Rails和Dropwizard越来越受欢迎，它用于指示身体的非句法问题。这种增长趋势向使用API的开发人员发出强烈信号，他们需要排除语法并专注于正文。开发人员的时间通常是客户所承受的最大单项成本，因此通过引导开发人员的注意力，您将使他们满意。

所以409是一个可能的答案，虽然相当新颖，422是更传统的方法，虽然显然RoR和DropWizard都是新的，所以这些惯例可以说是快速变化！

Answer 3

我说422在你的情况下是足够的，但如果它与你的其他API一致，则400不是坏事。当客户端出现问题时，使用400作为保护伞错误代码是常见的惯例，但错误并不适合特定的错误代码，或者您没有想要使用太多它们。

如果POST有效负载出现问题，那么404绝对是错误的。

Answer 4

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

案例2：帐户已关闭。如果您在关闭帐户时保留帐户详细信息，则这与逻辑有关。如果您在帐户关闭时没有保留帐户详细信息，则可以提供404。如果您在关闭后保留帐户详细信息，则必须对其进行标记（例如提高标记）（或者您拥有的任何逻辑）。在这种情况下，状态代码400具有正确的失败原因以及可能的补救措施。

案例3：确定的帐户不是正确的帐户。 403，因为帐户未被授权完成任何购买对我有意义。如果没有像授权帐户这样的概念，则会有400解释性消息。但在这种情况下我会坚持使用403。

Answer 5

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

400对422响应POST引用未知实体

5 个答案: