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

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

Edit

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

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

200好了 204无内容

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

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

为什么不用410呢?它表示所请求的资源不再存在，客户端希望永远不会对该资源发出请求，在您的例子中是users/9。

你可以在这里找到更多关于410的详细信息:https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

根据w3的帖子，

200好了

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

202年接受

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

204无内容

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

400错误请求

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

401年未经授权

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

404未找到

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

根据RFC7231 -第59页(https://www.rfc-editor.org/rfc/rfc7231#page-59) 404状态码响应的定义是:

6.5.4. 404 Not Found The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent. A 404 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).

而引起质疑的主要是上述语境中对资源的定义。 根据同一个RFC(7231)， resource的定义是:

Resources: The target of an HTTP request is called a "resource". HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resources. Each resource is identified by a Uniform Resource Identifier (URI), as described in Section 2.7 of [RFC7230]. When a client constructs an HTTP/1.1 request message, it sends the target URI in one of various forms, as defined in (Section 5.3 of [RFC7230]). When a request is received, the server reconstructs an effective request URI for the target resource (Section 5.5 of [RFC7230]). One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the request semantics in the request method (Section 4) and a few request-modifying header fields (Section 5). If there is a conflict between the method semantics and any semantic implied by the URI itself, as described in Section 4.2.1, the method semantics take precedence.

所以在我的理解中，404状态代码不应该用于成功的GET请求，结果为空。(例如:一个没有特定过滤器结果的列表)

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

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

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