请给我提供一些官方规范示例或可以证明我的业务合作伙伴的可信建议，这些示例可以证明我的业务伙伴从REST端点返回空列表时，HTTP状态应为200，而不是404。对于我来说，RFC-2616很明显，但也很笼统，因此不会讨论空集的情况。我正在寻找强有力的论据进行讨论。
亲切的问候， 卡米尔。
答案 0 :(得分：2)
RFC 2616是一个过时的文档。 404状态码的当前规范为RFC 7231 § 6.5.4，对我来说似乎很清楚：
404（未找到）状态代码表示原始服务器已执行 找不到目标资源的当前表示或找不到 愿意透露一个人的存在。
如果空白列表是您资源的有效表示形式（例如，与错误消息相反），则排除404。
答案 1 :(得分：2)
您将找不到任何“官方”内容。 REST只是一种体系结构样式，可以应用于HTTP的使用。
我的观点：如果资源标识某种容器，并且该容器存在但为空，则应为200。如果该容器不存在，则为404。因此，它很大程度上取决于资源的定义。
答案 2 :(得分：1)
请给我提供一些官方规范示例或可以证明我的业务合作伙伴的可信建议，这些示例可以证明我的业务伙伴从REST端点返回空列表时，HTTP状态应为200，而不是404。对于我来说，RFC-2616很明显，但也很笼统，因此不会讨论空集的情况。
如@Vasiliy Faronov所述，RFC 7231描述了200 OK的语义； “您要求提供资源的当前表示形式，就在这里。”
重要的是要认识到状态码是元数据，它描述了文档传输应用程序域中响应的性质。它没有告诉您有关文档本身的特定领域解释的任何信息。
我正在寻找有力的讨论依据。
https://www.google.com/search?q=C71151CF-5D9B-412F-A0EF-EBE90782800C
如果您向Google提交这样的查询，您将获得一个HTML页面作为响应，该页面的内容部分为：
您的搜索-C71151CF-5D9B-412F-A0EF-EBE90782800C-没有匹配的文档。
Google服务器返回的status line返回了：
HTTP/2.0 200 OK
没错-在文档传输域中，一切正常：我们的请求很明智，服务器能够找到我们要查找的文档的当前表示形式，我们被允许访问，依此类推。 / p>
特定于搜索域的信息位于消息正文中，它告诉我们没有可用的文档与我们要搜索的内容匹配。
答案 3 :(得分：0)
这取决于返回空列表是仅仅因为这是请求资源的当前状态，还是因为客户端使用的 URL 不正确。
见https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4：
<块引用>10.4 客户端错误 4xx
4xx 类状态代码适用于客户端似乎出错的情况。
如果没有客户端错误，任何包括 404 在内的 4xx 响应都是不合适的。
此外，规范还在继续：
<块引用>除了响应 HEAD 请求时，服务器应该包含一个实体，其中包含对错误情况的解释，以及它是暂时的还是永久的情况。
因此，如果响应是 []（JSON 中的空列表）并且没有错误消息，则表明 404 不合适。也有可能 404 是合适的，但响应缺少错误消息。