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

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

根据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请求，结果为空。(例如:一个没有特定过滤器结果的列表)

我得说，两者都不太合适。 正如@anneb所说的，我也认为部分问题来自于使用HTTP响应代码来传输与RESTful服务相关的状态。REST服务关于其自身处理的任何信息都应该通过特定于REST的代码来传输。

1

我认为，如果HTTP服务器发现任何服务已经准备好响应它发送的请求，它不应该响应HTTP 404——最后，服务器找到了一些东西——除非处理请求的服务明确地告诉它。

让我们暂时假设以下URL: http://example.com/service/return/test。

Case A is that the server is “simply looking for the file on the file system“. If it is not present, 404 is correct. The same is true, if it asks some kind of service to deliver exactly this file and that service tells it that nothing of that name exists. In case B, the server does not work with “real” files but actually the request is processed by some other service – e.g. some kind of templating system. Here, the server cannot make any claim about the existence of the resource as it knows nothing about it (unless told by the service handling it).

如果没有来自服务的任何响应显式地要求不同的行为，HTTP服务器只能说3件事:

503，如果处理请求的服务没有运行或响应; 否则，作为HTTP服务器实际上可以满足请求-不管服务稍后会说什么; 400或404表示没有这样的服务(相对于“存在但脱机”)，并且没有找到其他服务。

2

回到手头的问题:我认为最干净的方法是除了前面提到的以外，不使用任何HTTP响应代码。如果服务存在并响应，HTTP代码应该是200。 响应应该在一个单独的报头中包含服务返回的状态——在这里，服务可以说

REST:EMPTY，例如，如果它被要求搜索某物，而该研究返回为空; REST:NOT FOUND，如果它被特别地请求某事物，“ID-like”-是一个文件名或一个ID的资源或条目号24等-并且没有找到特定的资源(通常，一个特定的资源被请求但没有找到); REST:如果发送的请求的任何部分不被服务识别，则为无效。

(注意，我故意用“REST:”作为前缀，以标记这样一个事实，即虽然它们可能具有与HTTP响应代码相同的值或措辞，但它们是完全不同的东西)

3

让我们回到上面的URL并检查用例B，其中服务指示HTTP服务器它不处理这个请求本身，而是将它传递给服务。HTTP只提供SERVICE返回的内容，它不知道任何关于返回/测试部分的内容，因为这是由SERVICE处理的。如果该服务正在运行，HTTP应该返回200，因为它确实找到了处理请求的东西。

SERVICE返回的状态(如上所述，希望在单独的头文件中看到)取决于实际期望的操作:

if return/test asks for a specific resource: if it exists, return it with a status of REST:FOUND; if that resource does not exist, return REST:NOT FOUND; this could be extended to return REST:GONE if we know it once existed and will not return, and REST:MOVED if we know it has gone hollywood if return/test is considered a search or filter-like operation: if the result set is empty, return an empty set in the type requested and a status of REST:EMPTY; a set of results in the type requested and a status of REST:SUCCESS if return/test is not an operation recogized by SERVICE: return REST:ERROR if it is completely wrong (e.g. a typo like retrun/test), or REST:NOT IMPLEMENTED in case it is planned for later.

4

这种区别比把两种不同的东西混在一起要清楚得多。它还将使调试更容易，处理也只是稍微复杂一些。

如果返回一个HTTP 404，服务器会告诉我，“我不知道你在说什么”。虽然请求的REST部分可能完全没问题，但我在所有错误的地方都在寻找par'Mach。 另一方面，HTTP 200和REST:ERR告诉我，我得到了服务，但在对服务的请求中做了错误的事情。 从HTTP 200和REST:EMPTY，我知道我没有做错什么-正确的服务器，服务器找到了服务，正确的请求到服务-但搜索结果是空的。

总结

这个问题和讨论源于这样一个事实:HTTP响应码被用来表示由HTTP提供结果的服务的状态，或者用来表示不在HTTP服务器本身范围内的事物。 由于这种差异，这个问题无法回答，所有的意见都要经过大量的讨论。

由服务而不是HTTP服务器处理的请求的状态真的不应该(RFC 6919)由HTTP响应代码给出。HTTP代码应该(RFC 2119)只包含HTTP服务器从自己的作用域提供的信息:即，是否发现服务在处理请求。

相反，应该使用一种不同的方式将请求的状态告知使用者，以告知实际处理请求的服务。我的建议是通过一个特定的头文件来实现。理想情况下，报头的名称及其内容都遵循一种标准，使使用者可以很容易地处理这些响应。

起初，我认为204是有意义的，但经过讨论，我相信404是唯一真正正确的回答。考虑以下数据:

用户:约翰，彼得

METHOD  URL                      STATUS  RESPONSE
GET     /users                   200     [John, Peter]
GET     /users/john              200     John
GET     /unknown-url-egaer       404     Not Found
GET     /users/kyle              404     User Not found
GET     /users?name=kyle`        200     []
DELETE  /users/john              204     No Content

背景知识:

the search returns an array, it just didn't have any matches but it has content: an empty array. 404 is of course best known for url's that aren't supported by the requested server, but a missing resource is in fact the same. Even though /users/:name is matched with users/kyle, the user Kyle is not available resource so a 404 still applies. It isn't a search query, it is a direct reference by a dynamic url, so 404 it is. After suggestions in the comments, customizing the message of the 404 is another way of helping out the API consumer to even better distinguish between complete unknown routes and missing entities.

不管怎样，我的意见。

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

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.

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

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