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.

这个话题中的答案(在撰写本文时已经有26个)完美地说明了开发人员理解他们正在使用的构造的语义是多么重要。

如果不理解这一点，那么响应状态代码是响应的属性而不是其他属性就不明显了。这些代码存在于响应的上下文中，它们在此上下文中之外的含义是未定义的。

响应本身就是请求的结果。请求对资源进行操作。资源、请求、响应和状态代码是HTTP的结构，就HTTP而言:

HTTP提供了与资源(第2节)交互的统一接口，无论其类型、性质或实现如何，通过操作和传输表示(第3节)。

换句话说，响应状态码的范围受到一个接口的限制，该接口只关心一些目标资源，并处理用于与这些资源交互的消息。服务器应用程序逻辑超出了范围，您使用的数据也不重要。

当使用HTTP时，它总是与资源一起使用。资源被以太转移或操纵。在任何情况下，除非我们在量子世界中，资源要么存在要么不存在，不存在第三种状态。

如果发出HTTP请求来获取(传输)资源的表示(如本问题中所示)，而资源不存在，则响应结果应该显示一个带有相应404代码的失败。目标-获取表示-没有达到，资源没有找到。在HTTP上下文中不应该有对结果的其他解释。

RFC 7231超文本传输协议(HTTP/1.1):语义和内容，在这里多次提到，但主要是作为状态码描述的参考。我强烈建议通读整个文档，而不仅仅是第6节，以便更好地理解HTTP接口及其组件的作用域和语义。

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

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

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

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

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

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

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

Just an addition from a developer that struggled many times with this situation. As you might have noticed it is always a discussion whether you return a 404 or 200 or 204 when a particular resource does not exist. The discussion above shows that this topic is pretty confusing and opinion based ( while there is a http-status-code standard existing ). I personally recommend, as it was not mentioned yet I guess, no matter how you decide DOCUMENT IT IN YOUR API-DEFINITION. Of course a client-side developer has in mind when he/she uses your particular "REST"- api to use his/her knowledge about Rest and expects that your api works this way. I guess you see the trap. Therefor I use a readme where I explicitly define in which cases I use which status code. This doesn't mean that I use some random definion. I always try to use the standard but to avoid such cases I document my usage. The client might think you are wrong in some specific cases but as it is documented, there is no need for additional discussions what saves time for you and the developer.

One sentence to the Ops question: 404 is a code that always comes in my mind when I think back about starting to develop backend-applications and I configured something wrong in my controller-route so that my Controller method is not called. With that in mind, I think if the request does reach your code in a Controller method, the client did a valid request and the request endpoint was found. So this is an indication not to use 404. If the db query returns not found, I return 200 but with an empty body.