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

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

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

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

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

TL; diana:

如果在/users/9上没有找到用户，则应该返回404。 如果在/users中没有找到用户?如果Id =9，则应该返回204。

长版:

在回顾了我自己对这些状态代码的使用和本文中的示例之后，我不得不说，如果在/users/9的url上没有找到用户#9,404是适当的响应。

今天在我的系统中，我们的Application Insights日志中充满了数百条记录的404错误，这使我们的日志变得混乱，因为我们决定在/users/9没有相关数据时返回404错误。然而，这并不意味着我们在设置响应时的方法是不正确的，相反，我认为这意味着我们在设置路由时的方法是不正确的。

如果您希望端点获得大量流量，并且担心记录太多404错误，那么您应该更改路由以符合您想要的状态码，而不是强制使用不适当的状态码。

我们已经决定对我们的代码做2个更改:

通过expect /users改变我们的工作路线?id = 9 将我们的错误代码更改为204，这样404就不会填满我们的AI日志。

最后，API的架构师需要了解他们的API将如何被使用，以及哪种路由将适合于该用例。

我相信在/users/9的情况下，您请求的资源是用户本身，用户#9;您要求服务器响应一个标识为“9”的对象，该对象恰好存在于包含单词“user”的路径中。如果没有找到该对象，则应该得到404。

但是，如果调用/users?id=9，我觉得你所请求的资源是用户控制器，同时也提供了更多的专一性，这样它就不会返回所有用户的完整列表。您要求服务器响应一个可以通过查询字符串中定义的ID号识别的特定用户。因此，如果没有找到数据，204对我来说是有意义的，因为即使没有找到数据，控制器也是。

查询字符串方法还完成了一些我认为不仅有助于API开发人员，而且有助于客户端开发人员(特别是初级开发人员或继承这段代码或调用它的代码的未来开发人员):

It becomes immediately clear to anyone involved that 9 is an ID, not some arbitrary number. This point may seem moot in such a basic example, but consider a system that uses GUIDs as row ID's or allows you to get data by a person's name, or even a system that is returning info for specific ZIP/postal codes instead of row ID's. It would be useful for all developers involved if, at a glance, they knew whether that identifying parameter was a first, last, full name, or a ZIP/postal code instead of an ID.

现有的答案没有详细说明使用路径参数还是查询参数是有区别的。

In case of path parameters, the parameter is part of the resource path. In case of /users/9, the response should be 404 because that resource was not found. /users/9 is the resource, and the result is unary, or an error, it doesn't exist. This is not a monad. In case of query parameters, the parameter is not part of the resource path. In case of /users?id=9, the response should be 204 because the resource /users was found but it could not return any data. The resource /users exists and the result is n-ary, it exists even if it is empty. If id is unique, this is a monad.

使用路径参数还是查询参数取决于用例。我更喜欢将路径参数用于强制的、规范的或标识参数，将查询参数用于可选的、非规范的或属性参数(如分页、排序区域设置等)。在REST API中，我会使用/users/9而不是/users?Id =9，特别是因为可能嵌套获取“子记录”，如/users/9/ SSH -keys/0获取第一个公共SSH密钥或/users/9/address/2获取第三个邮政地址。

我更喜欢使用404。原因如下:

Calls for unary (1 result) and n-ary (n results) methods should not vary for no good reason. I like to have the same response codes if possible. The number of expected results is of course a difference, say, you expect the body to be an object (unary) or an array of objects (n-ary). For n-ary, I would return an array, and in case there are not results, I would not return no set (no document), I would return an empty set (empty document, like empty array in JSON or empty element in XML). That is, it's still 200 but with zero records. There's no reason to put this information on the wire other than in the body. 204 is like a void method. I would not use it for GET, only for POST, PUT, and DELETE. I make an exception in case of GET where the identifiers are query parameters not path parameters. Not finding the record is like NoSuchElementException, ArrayIndexOutOfBoundsException or something like that, caused by the client using an id that doesn't exist, so, it's a client error. From a code perspective, getting 204 means an additional branch in the code that could be avoided. It complicates client code, and in some cases it also complicates server code (depending on whether you use entity/model monads or plain entities/models; and I strongly recommend staying away from entity/model monads, it can lead to nasty bugs where because of the monad you think an operation is successful and return 200 or 204 when you should actually have returned something else). Client code is easier to write and understand if 2xx means the server did what the client requested, and 4xx means the server didn't do what the client requested and it's the client's fault. Not giving the client the record that the client requested by id is the client's fault, because the client requested an id that doesn't exist.

最后一点:一致性

GET /用户/ 9 PUT /users/9和DELETE /users/9

PUT /users/9和DELETE /users/9已经必须在成功更新或删除的情况下返回204。如果用户9不存在，它们应该返回什么?根据所使用的HTTP方法将相同的情况显示为不同的状态代码是没有意义的。

Besides, not a normative, but a cultural reason: If 204 is used for GET /users/9 next thing that will happen in the project is that somebody thinks returning 204 is good for n-ary methods. And that complicates client code, because instead of just checking for 2xx and then decoding the body, the client now has to specifically check for 204 and in that case skip decoding the body. Bud what does the client do instead? Create an empty array? Why not have that on the wire, then? If the client creates the empty array, 204 is a form of stupid compression. If the client uses null instead, a whole different can of worms is opened.

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

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

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

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

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

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

想想这个例子:

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

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

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

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

(厚颜无耻的注意。)

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

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

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

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