令人难过的是，如此简单和明确的东西在这个帖子中变成了“基于意见的”。

HTTP服务器只知道“实体”，这是对任何内容的抽象，可以是静态网页、搜索结果列表、其他实体列表、某物的json描述、媒体文件等等。

每个这样的实体都应该由一个唯一的URL来识别，例如。

/user/9——一个单独的实体:user ID=9 /users——单个实体:所有用户的LIST /media/x.mp3——一个单独的实体:一个名为x.mp3的媒体文件 /search—单个实体:基于查询参数的动态CONTENT

如果服务器通过给定的URL找到一个资源，那么它的内容是什么并不重要——2G的数据、null、{}、[]——只要它存在，它就会是200。但是如果服务器不知道这个实体，它将返回404“not Found”。

One confusion seems to be from developers who think if the application has a handler for a certain path shape, it should not be an error. In the eyes of the HTTP protocol it does not matter what happened in the internals of the server (ie. whether the default router responded or a handler for a specific path shape), as long as there is no matching entity on the server to the requested URL (that requested MP3 file, webpage, user object etc), which would return valid contents (empty or otherwise), it must be 404 (or 410 etc).

另一个令人困惑的地方似乎是“没有数据”和“没有实体”。前者是关于实体的内容，后者是关于实体的存在。

示例1:

No data: /users返回200 OK，正文:[]，因为还没有人注册 没有实体:/users返回404，因为没有路径/users

示例2:

No data: /user/9返回返回200 OK，正文:{}，因为用户ID=9从未输入他/她的个人数据 没有实体:/user/9返回404，因为没有用户ID=9

示例3:

No data: /search?name=Joe返回200 OK[]，因为DB中没有Joe 没有实体:/search?name=Joe返回404，因为没有路径/搜索

使用公共枚举对响应内容进行编码，以允许客户端打开它并相应地派生逻辑。我不知道你的客户如何区分“数据未找到”404和“网络资源未找到”404之间的区别?您不希望有人浏览到userZ/9，并让客户端怀疑请求是否有效，但没有返回数据。

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

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

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

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

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

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

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

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

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.

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

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

根据w3，我相信以下几点:

2xx:

这类状态代码表示成功接收、理解并接受了客户机的请求。

4xx:

4xx类状态代码用于客户端似乎出现错误的情况。

如果客户端请求/users，并且它有用户要列出，响应代码将是200 OK(客户端请求有效)。

如果客户端请求/users并且没有数据，响应代码仍然是200 OK。 被请求的实体/资源是一个用户列表，列表存在，只是其中没有任何用户(如果给出空响应，可以使用204 No Content，尽管我认为空列表[]会更好)。 客户端请求是有效的，资源也确实存在，因此4xx响应代码在这里没有意义。

另一方面，如果客户端请求/users/9，而该用户不存在，那么客户端就犯了一个错误，请求了一个不存在的资源，一个用户。在这种情况下，回答404 Not Found是有意义的。