根据微软:控制器动作返回类型在ASP。NET Core web API，向下滚动几乎到底部，你会发现下面关于404的简介，与数据库中没有的对象有关。在这里，他们建议404适用于空数据。

在这个场景中，Ruby on Rails响应404 Not Found。

客户端请求不存在的资源。因此，404 Not Found更合适。

Edit

我发现，在这种情况下，许多开发人员不喜欢找不到404。

如果您不想使用404，我认为，您可以使用以下两个响应代码中的任何一个:

200好了 204无内容

如果你使用200 OK:响应体应该是空json:[]或{}

如果你使用204 OK:响应体应该为空。

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

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

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

1.—资源为:/users

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

so:

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

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

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

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

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

希望能有所帮助。

如果期望资源存在，但它可能是空的，我认为它可能更容易得到一个200 OK的表示，表明这个东西是空的。

因此，我宁愿让/things返回一个带有{"Items":[]}的200 OK，而不是一个没有任何内容的204，因为这样，一个包含0项的集合可以被视为一个包含一个或多个项目的集合。

我将把204 No Content留给put和delete，在这种情况下，可能真的没有有用的表示。

在/thing/9不存在的情况下，404是合适的。

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

2xx:

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

4xx:

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

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

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

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

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

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，因为没有路径/搜索