请给我一些官方规范的例子,或者可以证明我的业务合作伙伴从 REST 端点返回一个空列表时的可信建议,HTTP 状态应该是 200,而不是 404。对我来说,RFC-2616 是显而易见的,但也是通用的并且不讨论结果为空集的情况。我正在寻找强有力的论据进行讨论。
亲切的问候,卡米尔。
请给我一些官方规范的例子,或者可以证明我的业务合作伙伴从 REST 端点返回一个空列表时的可信建议,HTTP 状态应该是 200,而不是 404。对我来说,RFC-2616 是显而易见的,但也是通用的并且不讨论结果为空集的情况。我正在寻找强有力的论据进行讨论。
亲切的问候,卡米尔。
你不会找到任何“官方”的东西。REST 只是一种架构风格,可以应用于 HTTP 的使用。
我的看法:如果资源标识了某种容器,并且容器存在,但为空,则应该是 200。如果容器不存在,则为 404。所以这很大程度上取决于资源的定义。
RFC 2616 是一个过时的文档。404 状态码的当前规范是RFC 7231 § 6.5.4,这对我来说似乎很清楚:
404(未找到)状态代码表示源服务器没有找到目标资源的当前表示或不愿意透露存在的表示。
如果空列表是您的资源的有效表示(例如,与错误消息相反),则排除 404。
请给我一些官方规范的例子,或者可以证明我的业务合作伙伴从 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 - 没有匹配任何文档。
谷歌服务器返回的状态行返回:
HTTP/2.0 200 OK
没错——在文档传输域中,一切正常:我们的请求是合理的,服务器能够找到我们请求的文档的当前表示,我们被允许访问它,等等。
搜索域特定信息在消息正文中,它告诉我们没有可用的文档与我们正在搜索的内容相匹配。
这取决于返回空列表是否仅仅是因为这是所请求资源的当前状态,还是因为客户端使用的 URL 不正确。
请参阅https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4:
10.4 客户端错误 4xx
4xx 类状态码适用于客户端似乎出错的情况。
如果没有客户端错误,则包括 404 在内的任何 4xx 响应都是不合适的。
此外,规范继续:
除了响应 HEAD 请求时,服务器应该包含一个实体,其中包含对错误情况的解释,以及它是暂时的还是永久的情况。
因此,如果响应是[]
(JSON 中的空列表)并且没有错误消息,则表明 404 不合适。404 也可能是合适的,但响应缺少错误消息。