我强烈反对404，而支持204或200的空数据。或者至少应该使用带有404的响应实体。

请求被接收并被正确处理——它确实触发了服务器上的应用程序代码，客户机可能没有犯任何错误，因此整个客户机错误代码(4xx)类可能不合适。

更重要的是，404的发生有很多技术原因。例如，应用程序在服务器上被暂时停用或卸载，代理连接问题等等。

当然，这种情况下存在5xx错误类，但实际上，受影响的中间件组件通常无法知道错误在它们这一边，然后只是假设错误在客户端，然后响应404而不是500/503。

因此，仅根据状态代码，客户端无法区分404(表示“您正在寻找的东西不存在”)和404(表示“有严重错误，请将此错误报告给运维团队”)。

This can be fatal: Imagine an accounting service in your company that lists all the employees that are due to an annual bonus. Unfortunately, the one time when it is called it returns a 404. Does that mean that no-one is due for a bonus, or that the application is currently down for a new deployment and the 404 is actually coming from the tomcat that it's supposed to be installed into, instead of from the application itself? These two scenarios yield the same status code, but they are fundamentally different in their meaning.

对于需要知道所请求的资源不存在而不是暂时不可访问的应用程序来说，没有响应实体的404几乎是行不通的。

此外，许多客户端框架通过抛出异常来响应404，而不询问进一步的问题。这迫使客户端开发人员捕获异常，对其进行评估，然后基于此决定是否将其记录为由监视组件捕获的错误，或者是否忽略它。这对我来说也不太好。

The advantage of 404 over 204 is that it can return a response entity that may contain some information about why the requested resource was not found. But if that really is relevant, then one may also consider using a 200 OK response and design the system in a way that allows for error responses in the payload data. Alternatively, one could use the payload of the 404 response to return structured information to the caller. If he receives e.g. a html page instead of XML or JSON that he can parse, then that is a good indicator that something technical went wrong instead of a "no result" reply that may be valid from the caller's point of view. Or one could use a HTTP response header for that.

尽管如此，我还是更喜欢204或200的空白回复。这样，请求的技术执行状态就与请求的逻辑结果分开了。2xx的意思是“技术执行ok，这就是结果，处理它”。

我认为在大多数情况下，应该让客户来决定一个空的结果是否可以接受。通过返回404而不返回响应实体(尽管技术执行正确)，客户端可能决定将根本不是错误的情况视为错误。

Another perspective: From an operations point of view a 404 may be problematic. Since it can indicate a connectivity/middleware problem rather than a valid service response, i would not want a fluctuating number of "valid" 404s in my metrics/dashboards that might conceal genuine technical issues (e.g. a misconfigured proxy somewhere in the request routing) that should be investigated and fixed. This is further excarbated by some APIs even using 404 instead of 401/403 (e.g. gitlab does such a thing), to conceal the information that the request URI would have been valid but the request lacked authorization to access it. In this case too a 404 should be treated as a technical error and not as a valid "resource not found" result.

Edit: Wow, this has caused a lot of controversy. Here is another argument against 404: Strictly from a HTTP spec (RFC7231) point of view, 404 does not even mean that a resource does not exist. It only means that the server has no current representation of the requested resource available, and this even may be only temporary. So strictly by HTTP spec, 404 is inherently unreliable regarding the nonexistence of a requested thing. If you want to communicate that the requested thing positively does not exist, do not use 404.

根据RFC7231 -第59页(https://www.rfc-editor.org/rfc/rfc7231#page-59) 404状态码响应的定义是:

6.5.4. 404 Not Found The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent. A 404 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).

而引起质疑的主要是上述语境中对资源的定义。 根据同一个RFC(7231)， resource的定义是:

Resources: The target of an HTTP request is called a "resource". HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resources. Each resource is identified by a Uniform Resource Identifier (URI), as described in Section 2.7 of [RFC7230]. When a client constructs an HTTP/1.1 request message, it sends the target URI in one of various forms, as defined in (Section 5.3 of [RFC7230]). When a request is received, the server reconstructs an effective request URI for the target resource (Section 5.5 of [RFC7230]). One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the request semantics in the request method (Section 4) and a few request-modifying header fields (Section 5). If there is a conflict between the method semantics and any semantic implied by the URI itself, as described in Section 4.2.1, the method semantics take precedence.

所以在我的理解中，404状态代码不应该用于成功的GET请求，结果为空。(例如:一个没有特定过滤器结果的列表)

看完疑问后，为什么不应该使用404 ?

根据RFC 7231，正确的状态码是204

在上面的回答中，我注意到一个小错误:

1.—资源为:/users

2.- /users/8不是资源，而是:路由参数为8的资源/users，消费者可能注意不到，也不知道区别，但是发布者知道，而且必须知道!所以他必须为消费者返回一个准确的响应。时期。

so:

基于RFC: 404是不正确的，因为找到了资源/用户，但是使用参数8执行的逻辑没有找到任何内容作为响应返回，因此正确的答案是:204

这里的要点是:404甚至没有找到处理内部逻辑的资源

204是a:我找到了资源，逻辑被执行了，但我没有发现任何数据使用你在路由参数中给出的标准，所以我不能返回任何东西给你。对不起，核实你的标准后再打电话给我。

200:好吧，我找到了资源，逻辑被执行(即使当我不被迫返回任何东西)采取这一点，并在你的意愿使用它。

205:(GET响应的最佳选项)我找到了资源，逻辑被执行了，我有一些内容给你，好好使用它，哦，顺便说一下，如果你要在视图中共享这个，请刷新视图以显示它。

希望能有所帮助。

Twitter使用404，并带有类似“找不到数据”的自定义错误消息。

裁判:https://developer.twitter.com/en/docs/basics/response-codes.html

正如许多人所说的，404会误导客户端，如果请求uri不存在，或者请求的uri不能获取请求的资源，它不允许客户端进行区分。

200状态被期望包含资源数据——所以它不是正确的选择。 204状态意味着完全不同的东西，不应该用作GET请求的响应。

由于这样或那样的原因，所有其他现有状态都不适用。

我看到这个话题在很多地方被反复讨论。对我来说，很明显，要消除围绕这个话题的困惑，就需要一个专门的成功状态。比如“209 -没有资源显示”。

这将是一个2xx状态，因为找不到ID不应该被认为是客户端错误(如果客户端知道服务器DB中的所有内容，它们就不需要向服务器询问任何事情，不是吗?)这个专用状态将解决所有与使用其他状态争论的问题。

唯一的问题是:我如何让RFC接受这个标准?

我不认为404是正确的回应。

如果使用404，如何知道是没有找到api，还是数据库中的记录没有找到?

从你的描述，我会使用200 OK，因为你的api执行所有逻辑没有任何问题。只是在数据库中找不到记录。所以，这不是API问题，也不是数据库问题，这是你的问题，你认为记录存在，但它不存在。因此，API执行成功，数据库查询执行成功，但没有发现任何返回。

因此，在这种情况下，我会用

200好了

使用空响应，如数组的[]或对象的{}。