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

2xx:

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

4xx:

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

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

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

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

在以前的项目中，我使用了404。如果没有用户9，则没有找到对象。因此404 Not Found是合适的。

如果对象存在，但没有数据，则为204 no Content。我认为在你的例子中，这个物体并不存在。

我们现在看到的是两种范式之间的紧张关系。

在HTTP和REST中，URL标识一个资源，该用户/9资源包括9。因此HTTP应该返回404—未找到。这就是RESTful的定义。之后，你可以PUT user/9，然后当你得到下一次，你得到数据。这就是HTTP和REST的设计方式。

在HTTP级别，如果你不想要404，一个更好的URL会是user?Id =9，那么用户部分将被找到，函数可以进行自己的处理并返回它自己的“未找到”通知。

然而，为了方便指定api，使用user/9格式“更好”。这给我们留下了一个困境:这个请求是通过HTTP发出的，(固执的)正确的HTTP答案是404;但是从API使用者的角度来看，框架可能不能很好地处理404，他们想要200 +一个“not found”有效负载(204对许多框架来说也可能是问题)。

这种将API放在已经定义的协议(HTTP)之上的做法导致了这种紧张。当设计成一个真正的RESTful API时(并且正确地处理404错误)，这是没有问题的。

如果您认为user/9应该返回200 +“not found”，那么您使用user作为RPC端点，然后在URL的其余部分编码参数。我认为这是一种糟糕的设计，与RESTful规范相反，并且完全理解我们是如何走到这一步的。

如果你控制了两端，考虑到你的服务器和客户端框架的限制，就做那些有效的事情。

(想想在用户/9上执行HEAD请求的后果——你不能在响应中提供任何内容。200将表明用户/9确实存在，而404将(正确地)表明它不存在。)

如果仅仅因为没有响应数据而返回404，则任何客户端都会感到非常困惑。

对我来说，响应代码200和一个空的主体足以理解一切都是完美的，但没有数据匹配的要求。

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

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

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

1.—资源为:/users

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

so:

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

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

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

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

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

希望能有所帮助。

为了总结或简化，

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

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

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