例如,你运行一个GET请求,users/9
但没有ID#9的用户。哪个是最好的响应代码?
发布于 2018-03-22 19:22:43
我强烈反对404支持204或200个空数据。
该请求已收到并正确处理 - 它确实触发了服务器上的应用程序代码,因此不能真正说它是客户端错误,因此整个客户端错误代码(4xx)不适合。
更重要的是,404可能会出于多种技术原因。例如,应用程序暂时停用或卸载在服务器上,代理连接问题等等。因此,客户端无法区分404表示“空结果集”和404表示“服务无法找到,稍后再试”的404。
这可能是致命的:想象一下贵公司的一个会计服务,列出所有因年度奖金而发生的员工。不幸的是,有一次,它被称为它会返回一个404。这是否意味着没有人应该获得奖金,或者应用程序目前正在进行新部署?
- >对于关注数据质量的应用程序,404因此几乎是不行的。
而且,许多客户端框架通过抛出异常来回应404,而不再提出任何问题。这会强制客户端开发人员捕获该异常,对其进行评估,然后根据是否将其记录为由监视组件拾取的错误或是否忽略该错误来决定。这对我来说也不是很好。
与204相比,404的唯一优点是它可以返回一个响应实体,该实体可能包含一些关于为什么找不到请求的资源的信息。但是,如果这真的是相关的,那么人们也可以考虑使用200 OK响应并以允许有效载荷数据中的错误响应的方式来设计该系统。或者,可以使用404响应的有效负载将结构化信息返回给调用者。如果他收到一个html页面,而不是他可以解析的XML或JSON,那么这是一个很好的指标,表明技术出错了,而不是从调用者的角度来看可能是有效的“无结果”答复。或者可以使用HTTP响应标题。
尽管如此,我仍然更喜欢204或200的空响应。这样,请求的技术执行状态与请求的逻辑结果分离。2xx的意思是“技术执行好,这是结果,处理它”。
我认为在大多数情况下,应由客户决定是否可以接受空的结果。尽管技术执行正确,客户仍可以通过返回404来决定将案例看作是没有错误的错误。
另一个快速的比喻:对于“找不到结果”返回404就像抛出DatabaseConnectionException,如果SQL查询没有返回结果。它可以完成工作,但有很多可能的技术原因会抛出相同的异常,然后将其误认为是有效的结果。
https://stackoverflow.com/questions/-100003214
复制相似问题