正确的REST响应为空表？
假设您想通过调用get api/users来获取用户列表，但是目前表被截断，所以没有用户。 什么是这种情况下404或204的正确答案？
我也不会说。
为什么不404（没有find）？
404状态码应该保留用于没有find资源的情况。 在这种情况下，您的资源是用户的集合 。 这个集合存在，但它目前是空的。 就我个人而言，如果我有一天200第二天404就是因为有人碰巧删除了一些用户，我会非常困惑，作为您的应用程序的客户端的作者。 我应该做些什么？ 我的url错了吗？ 有人更改了API并忽略了redirect。
为什么不是204（无内容）？
这里是w3c对204状态码的描述摘录
服务器已经完成了请求，但不需要返回实体主体，并且可能想要返回更新后的元信息。
虽然在这种情况下这似乎是合理的，但我认为这也会使客户混淆。 204表示某个操作已经成功执行，不需要返回任何数据。 作为对DELETE请求的响应或者可能引发一些不需要返回数据的脚本，这是完美的。 在api/users情况下，您通常希望收到您的用户集合的表示forms。 一次发送一个响应体而另一次不发送响应体是不一致的并且可能会引起误解。
为什么我会用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（未find）
如果你没有桌子，这个答案是非常正确的。 不只是空表，但没有用户表。 它确认确切的想法 – 没有资源。 进一步的select是提供更多的细节为什么你的表缺席，有几个更详细的代码，但404是很好的指的是你真的没有表的情况。
200（OK）
所有的情况下，你有表，但它是空的或您的请求处理器筛选出所有结果。 这意味着“您的请求是正确的，一切正常，但是您没有匹配任何数据，只是因为我们没有数据，或者我们没有数据符合您的请求。 这应该是不同于安全否认的答案。 我也投票返回200的情况下，你有一些数据，一般你可以访问表，但无法访问所有符合您的请求的数据（由于对象级别的安全性，数据被过滤掉，但一般来说，您可以请求）。
如果您期待用户对象列表，最好的解决scheme是返回一个空列表（[]）比使用404或204响应。
