问对空表进行正确的REST响应？

EN

我会说，都不是。

为什么不是404 (找不到)？

404状态码应保留用于找不到资源的情况。在这种情况下，您的资源是用户的集合。此集合存在，但当前为空。就我个人而言，如果我一天得到一个200，第二天得到一个404，仅仅因为有人碰巧删除了几个用户，那么作为一个应用程序客户端的作者，我会感到非常困惑。我该怎么做？我的URL是错误的吗？是否有人更改了API并忽略了留下重定向。

为什么不是204 (无内容)？

以下是the description of the 204 status code by w3c的摘录

服务器已完成请求，但不需要返回entity-body，并且可能希望返回更新的元信息。

虽然在这种情况下这似乎是合理的，但我认为它也会让客户感到困惑。204应该表示某个操作已成功执行，不需要返回任何数据。这非常适合作为对DELETE请求的响应，或者触发一些不需要返回数据的脚本。对于api/users，您通常希望收到用户集合的表示形式。一次发送响应正文，而另一次不发送，这是不一致的，可能会产生误导。

为什么我要用200 (OK)

由于上面提到的原因(一致性)，我将返回一个空集合的表示。让我们假设您使用的是XML。非空用户集合的正常响应正文可能如下所示：

<users>
  <user>
    <id>1</id>
    <name>Tom</name>
  </user>
  <user>
    <id>2</id>
    <name>IMB</name>
  </user>
</users>

如果列表是空的，你可以像这样回复(同时仍然使用200)：

<users/>

无论采用哪种方式，客户端都会接收遵循某种众所周知的格式的响应体。没有不必要的混淆和状态码检查。此外，不违反任何状态代码定义。大家都很开心。

您可以对JSON或HTML或您正在使用的任何格式执行相同的操作。

根据运行时的情况，我会回答两个代码中的一个：

404 (未找到)

如果你没有表格，这个答案是非常正确的。不仅是空表，而且没有用户表。它证实了确切的想法-没有资源。更多的选项是提供你的表为什么没有的更多细节，有几个更详细的代码，但404非常适合于引用你真正没有表的情况。

200 (OK)

所有情况下，您有表，但它是空的，或者您的请求处理器过滤掉了所有结果。这意味着‘你的请求是正确的，一切正常，但你不匹配任何数据，只是因为我们没有数据或者我们没有与你的请求匹配的数据。这应该不同于安全拒绝回答。如果你有一些数据，通常你被允许访问表，但不能访问与你的请求匹配的所有数据，我也投票支持返回200。(由于对象级别的安全，数据被过滤掉了，但通常你可以请求)。

如果你期望用户对象列表，最好的解决方案是返回一个200OK的空列表([])，而不是使用404或204响应。