TL;DR:使用404

请看这个博客。这解释得很好。

博客对204的评论总结如下:

204 No Content作为浏览器的响应代码并不是特别有用(尽管根据HTTP规范，浏览器需要将其理解为“不要更改视图”的响应代码)。 然而，No Content对于ajax web服务非常有用，它可能想要表示成功而不需要返回任何东西。(特别是在DELETE或post这样不需要反馈的情况下)。

因此，您的问题的答案是在您的情况下使用404。204是一个专门的响应代码，您不应该经常将其返回给浏览器以响应GET。

其他响应代码甚至比204和404更不合适:

200 should be returned with the body of whatever you successfully fetched. Not appropriate when the entity you're fetching doesn't exist. 202 is used when the server has begun work on an object but the object isn't fully ready yet. Certainly not the case here. You haven't begun, nor will you begin, construction of user 9 in response to a GET request. That breaks all sorts of rules. 400 is used in response to a poorly formatted HTTP request (for instance malformed http headers, incorrectly ordered segments, etc). This will almost certainly be handled by whatever framework you're using. You shouldn't have to deal with this unless you're writing your own server from scratch. Edit: Newer RFCs now allow for 400 to be used for semantically invalid requests.

维基百科对HTTP状态码的描述尤其有用。 您也可以在www.w3.org上看到HTTP/1.1 RFC2616文档中的定义

这样的事情可能是主观的，双方都有一些有趣和各种扎实的论点。然而，(在我看来)为丢失的数据返回404是不正确的。这里有一个简单的描述来说明这一点:

请求:能给我一些数据吗? 资源(API端点):我将在这里为您获取请求[发送潜在数据的响应]

没有问题，找到了端点，找到了表和列，因此查询了DB，并“成功”返回了数据!

现在，无论“成功响应”是否有数据都不重要，您要求“潜在”数据的响应，并且具有“潜在”数据的响应得到了满足。Null，空等是有效的数据。

200只代表我们的请求成功了。我正在请求数据，HTTP/REST没有任何问题，作为数据(尽管为空)返回我的“数据请求”是成功的。

返回一个200，让请求者在每个特定场景下处理空数据!

想想这个例子:

请求:查询用户ID为1234的“违规”表 资源(API端点):返回一个响应，但数据为空

此数据为空是完全有效的。这意味着用户没有违规行为。这是200，因为它是有效的，然后我可以这样做:

你没有违规，吃个蓝莓松饼!

如果你认为这是404，你在说什么?无法发现用户的违规行为?从语法上讲，这是正确的，但在REST世界中，成功或失败是关于请求的，这是不正确的。该用户的“违规”数据可以成功找到，没有违规-一个实数代表有效状态。

(厚颜无耻的注意。)

在你的标题中，你下意识地认为200是正确的回答:

对于有效请求但空数据，正确的REST响应代码是什么?

在选择使用哪种状态码时，抛开主观性和棘手的选择，以下是一些需要考虑的事情:

一致性。如果您使用404表示“无数据”，则在每次响应返回无数据时使用它。 同一个状态不要有多个意思。如果在没有找到资源时返回404(例如API端点不存在等)，那么也不要因为没有返回数据而使用它。这只会让应对反应变成一种痛苦。 仔细考虑上下文。什么是“请求”?你说你想达到什么目的?

根据w3的帖子，

200好了

请求成功。随响应返回的信息取决于请求中使用的方法

202年接受

请求已接受处理，但处理尚未完成。

204无内容

服务器已经完成了请求，但不需要返回实体主体，并且可能希望返回更新后的元信息。

400错误请求

由于语法错误，服务器无法理解请求。客户不应该在没有修改的情况下重复请求

401年未经授权

请求需要用户身份验证。响应必须包含一个WWW-Authenticate报头字段

404未找到

服务器没有发现任何与Request-URI匹配的内容。没有说明这种情况是暂时的还是永久的

我强烈反对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.

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

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

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

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

200好了

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

如果仅仅因为没有响应数据而返回404，则任何客户端都会感到非常困惑。

对我来说，响应代码200和一个空的主体足以理解一切都是完美的，但没有数据匹配的要求。