rest - 有效请求但空数据的正确 REST 响应代码是什么？

Question

例如，您对 users/9 运行 GET 请求。但没有 ID #9 的用户。
哪个是最好的响应代码？

200 确定

202 接受

204 无内容

400 错误请求

404 未找到

Answer 1

我强烈反对 404 支持 204 或 200 有空数据。或者至少应该使用带有 404 的响应实体。
请求已被接收并正确处理 - 它确实触发了服务器上的应用程序代码，因此不能真正说它是客户端错误，因此整个客户端错误代码 (4xx) 类不合适。
更重要的是，404 可能由于多种技术原因而发生。例如。应用程序在服务器上被暂时停用或卸载，代理连接问题等等。因此，客户端无法区分表示“空结果集”的 404 和表示“找不到服务，稍后再试”的 404。
这可能是致命的:想象一下您公司的会计服务列出了所有应获得年度奖金的员工。不幸的是，当它被调用时，它会返回一个 404。这是否意味着没有人应得奖金，或者该应用程序当前因新部署而停机？
-> 对于关心数据质量的应用程序，没有响应实体的 404 因此几乎是不可行的。
此外，许多客户端框架通过抛出异常来响应 404，并且不再询问任何问题。这迫使客户端开发人员捕获该异常，对其进行评估，然后根据该异常决定是否将其记录为错误，例如监控组件或是否忽略它。这对我来说似乎也不漂亮。
404 相对于 204 的优势在于它可以返回一个响应实体，其中可能包含一些关于为什么找不到所请求的资源的信息。但如果这确实相关，那么人们也可以考虑使用 200 OK 响应并以允许有效负载数据中的错误响应的方式设计系统。
或者，可以使用 404 响应的有效负载将结构化信息返回给调用者。如果他收到例如一个 html 页面而不是他可以解析的 XML 或 JSON，那么这是一个很好的指标，表明出现了技术问题，而不是从调用者的角度来看可能是有效的“无结果”回复。或者可以为此使用 HTTP 响应 header 。
不过，我仍然更喜欢带有空响应的 204 或 200。这样，请求的技术执行状态与请求的逻辑结果是分开的。 2xx 表示“技术执行ok，这是结果，处理它”。
我认为在大多数情况下，应该由客户来决定是否可以接受空结果。尽管技术执行正确，但通过在没有响应实体的情况下返回 404，客户端可以决定将案例视为错误，而这些错误根本就不是错误。
另一个简单的类比:“未找到结果”返回 404 就像在 SQL 查询未返回任何结果时抛出 DatabaseConnectionException。它可以完成工作，但是有很多可能的技术原因会引发相同的异常，然后会被误认为是有效的结果。
另一个角度:从操作的角度来看，404 可能是有问题的。由于它可以指示连接问题而不是有效的服务响应，因此我不希望我的指标/仪表板中可能隐藏应该调查和修复的真正技术问题的“有效” 404 数量波动。