哪个状态码是正确的 404 或 400 以及何时使用其中任何一个？

Question

当我的资源中的对象不可用时应该返回什么状态码？

{
  "Id": 0,
  "name": "user1",
  "scheme": {
    "id": 15,
    "name": "scheme1"
  }
}

如果id为15的scheme不存在，应该是什么响应码？400还是404？

Answer 1

如果请求已执行到指向确实存在的资源的 URL，我认为 404 不适合这种情况。问题出在payload上，所以404与此无关。

JSON 文档的语法是有效的，所以400 也不合适。

由于数据无效，您拥有的是一个无法处理的实体，因此422 将是这里的最佳选择。继续阅读以获得更详细的说明。

未找到和错误请求

假设已经对定位到有效资源（即存在的资源）的URL执行了请求，返回404不适合这种情况，可能会产生误解：

6.5.4. 404 Not Found

404（未找到）状态码表示源服务器已 找不到目标资源的当前表示或不是 愿意透露一个存在。 404 状态码不 表明这种缺乏代表权是暂时的还是 永恒的; 410 (Gone) 状态码优先于404，如果 原始服务器可能通过一些可配置的方式知道， 这种情况很可能是永久性的。

如果 JSON 格式不正确，则返回 400 并在负载中包含描述性消息将适用于这种情况，但情况并非如此：

6.5.1. 400 Bad Request

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

无法处理的实体

事实上，您所拥有的是一个由于无效数据而无法被服务器处理的实体。因此，在响应负载中返回 422 和有关错误的详细信息将是最适合这种情况的方法：

11.2. 422 Unprocessable Entity

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

^{当它说 XML 时，只需阅读 JSON。}

您也可能会发现此answer 很有帮助。

HTTP API 的问题详情

HTTP 状态代码有时不足以传达有关错误的足够信息以提供帮助。 RFC 7807 定义了简单的 JSON 和 XML 文档格式，以通知客户端 HTTP API 中的问题。

它还定义了application/problem+json 和application/problem+xml 媒体类型。

选择正确的 4xx 状态码

在选择最合适的4xx 状态码时，下图（摘自this page）非常有见地。希望对您有所帮助：

Answer 2

当我的资源中的对象不可用时应该返回什么状态码？

Michael Kropat 为choosing an HTTP status code 整理了一个非常好的流程图。

第一步是确定您是否有错误。资源架构包含 optional 元素是完全合理的。如果这适合您的情况，那么只需使用 200 就可以了。

另一方面，如果是错误，您现在需要评估错误的原因。

如果问题源于请求，那么您应该查看状态码4xx class 中的条目。

4xx（客户端错误）类状态码表示客户端似乎出错了。

这些都是 HTTP 请求本身问题的变体；客户端不应该请求该资源，或者客户端需要在请求中包含不同的信息，或者...... RFC 7231 规定的许多不同的变体。

这里的启发是客户端可以通过发送不同的请求来修复问题。

另一方面，如果请求正常，但服务器现在无法响应正确，那么您应该查看5xx class

5xx（服务器错误）类状态码表示服务器知道自己出错或无法执行请求的方法。

5xx 类要小得多； 500 几乎总是正确的选择，协议不太关心将细节传达给客户端，因为客户端无法解决服务器问题。

从您的示例中，我最好的猜测是，您应该发送带有包含“错误情况说明”的有效负载的 500 响应，或者您应该发送带有包含表示的有效负载的 200 响应资源，即使该表示不包括所有可选元素。