对于未找到的资源集合，最合适的 HTTP 状态是什么？答案

【问题标题】：What's the most appropriate HTTP status for a resource collection not found?对于未找到的资源集合，最合适的 HTTP 状态是什么？
【发布时间】：2016-06-24 14:59:27
【问题描述】：

我们的应用程序不直接处理资源，也不支持与创建、更新、删除资源有关的各种 HTTP 动词。我们大多有返回资源集合的“finder”方法。所以我们可能有一个像/users?firstName=john 这样的URL，但不是/users/1。

我们正在讨论的问题是，如果没有找到名字为“john”的用户，什么是最合适的 HTTP 状态代码。我的观点是应该返回 204 表示一个空集合，而不是 404，因为集合本身不是资源，因此“找不到资源”不是有效的响应。 RFC 3986, section 3.4 说-

查询组件包含非分层数据，以及路径组件（第 3.3 节）中的数据，用于识别资源...

没有任何关于资源集合的说法。

想法？

【问题讨论】：

我很失望地看到有人投票结束了这个话题，然而，显然没有关于这个话题的共识。如果那个人有答案，他们应该发布它，而不是试图关闭一个完全有效的问题。

标签： rest http http-status-code-404

【解决方案1】：

我同意 404 状态在这里不合适。我个人会使用 200 状态和一个空集合，因为这清楚地表示“无结果”响应。

【讨论】：

为什么不像我的帖子中的 204，它说没有内容？没有任何关于 200 表示没有内容。
这无疑是非常有意见的（REST 很有趣），但作为客户端，我希望从查询中返回某种结果，即使该结果是一个空集合。没有响应主体的 204 会让我感到惊讶。话虽这么说，没有对错之分：如果 204 和任何实体对您来说更有意义，那就去吧！
@lutz-horn, brad-melanson，我回去阅读了 Roy Fielding 的原版PhD dissertation。在第 5.2.1.1 节“资源和资源标识符”>“REST 中信息的关键抽象是资源。任何可以命名的信息都可以是资源：文档或图像，时间服务（例如“洛杉矶今天的天气”） )、其他资源的集合、非虚拟对象（例如人）等等。”基于此，任何未找到的资源（包括集合）的 404 似乎都是正确的做法。

【解决方案2】：

您使用的是带有过滤器（查询参数）的集合资源。对集合资源的每个请求都应返回一个集合（可能是 JSON 数组）。

如果未应用过滤器，则完整的（可能是分页的）集合是资源。
如果应用了过滤器并且存在匹配项，则返回包含匹配项的集合。
如果应用了过滤器并且有 no 个匹配项，则返回一个 empty 集合。

请注意，在所有情况下，都会返回一个collectin，无论是有一个匹配项、没有匹配项还是只有一个匹配项。因此，如果使用 JSON，则响应永远不会为空，但至少包含一个空数组。

要使用的 HTTP 响应标头必须是 200 OK。由客户端解析资源表示并检测它是否为空。

【讨论】：

根据我的帖子中的 RFC 3986，查询参数与用于识别资源的路径变量一样好。我没有找到任何支持您的声明，即它们是 RFC 中的“过滤器”。另外，对于状态，为什么您认为状态“必须”是 200？您能否参考任何支持该声明的标准文献？
您是正确的，查询参数是用于标识资源的 URI 的一部分。问题是：资源是什么？如果您有 collection 资源，通常的做法是使用我的回答中描述的 HTTP 响应和状态代码。如果您不同意资源是集合，请告诉我们您的资源是什么。
在我的 URL 示例中，/users?firstName=john、User 是一个资源。除非集合有自己的 id，否则不能将其视为资源。将集合视为资源当然不常见，因为/users/1 不会为您提供 id 为 1 的用户集合，而是为您提供 id 为 1 的用户。
/users 给你什么？如果有多个名字为john 的用户，/users?firstName=john 的结果是什么？
GET /users 将按照约定返回所有用户。