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

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.

为了总结或简化，

2xx:可选数据:格式良好的URI: Criteria不是URI的一部分:如果Criteria是可选的，可以在@RequestBody和@RequestParam中指定，应该导致2xx。例如:按名称/状态过滤

标准是URI的一部分:如果标准是强制性的，只能在@PathVariable中指定，那么它应该导致4xx。例如:按唯一id查找。

对于所问的情况: "users/9"将是4xx(可能是404) 但是对于“用户”呢?Name =superman”应该是2xx(可能是204)

204号更合适。特别是当你有一个警报系统来确保你的网站是安全的，404在这种情况下会引起混乱，因为你不知道一些404警报是后端错误或正常的请求，但响应为空。

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

2xx:

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

4xx:

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

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

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

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

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

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

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

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

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

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

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

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