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

看完疑问后，为什么不应该使用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)

这个话题中的答案(在撰写本文时已经有26个)完美地说明了开发人员理解他们正在使用的构造的语义是多么重要。

如果不理解这一点，那么响应状态代码是响应的属性而不是其他属性就不明显了。这些代码存在于响应的上下文中，它们在此上下文中之外的含义是未定义的。

响应本身就是请求的结果。请求对资源进行操作。资源、请求、响应和状态代码是HTTP的结构，就HTTP而言:

HTTP提供了与资源(第2节)交互的统一接口，无论其类型、性质或实现如何，通过操作和传输表示(第3节)。

换句话说，响应状态码的范围受到一个接口的限制，该接口只关心一些目标资源，并处理用于与这些资源交互的消息。服务器应用程序逻辑超出了范围，您使用的数据也不重要。

当使用HTTP时，它总是与资源一起使用。资源被以太转移或操纵。在任何情况下，除非我们在量子世界中，资源要么存在要么不存在，不存在第三种状态。

如果发出HTTP请求来获取(传输)资源的表示(如本问题中所示)，而资源不存在，则响应结果应该显示一个带有相应404代码的失败。目标-获取表示-没有达到，资源没有找到。在HTTP上下文中不应该有对结果的其他解释。

RFC 7231超文本传输协议(HTTP/1.1):语义和内容，在这里多次提到，但主要是作为状态码描述的参考。我强烈建议通读整个文档，而不仅仅是第6节，以便更好地理解HTTP接口及其组件的作用域和语义。

Just an addition from a developer that struggled many times with this situation. As you might have noticed it is always a discussion whether you return a 404 or 200 or 204 when a particular resource does not exist. The discussion above shows that this topic is pretty confusing and opinion based ( while there is a http-status-code standard existing ). I personally recommend, as it was not mentioned yet I guess, no matter how you decide DOCUMENT IT IN YOUR API-DEFINITION. Of course a client-side developer has in mind when he/she uses your particular "REST"- api to use his/her knowledge about Rest and expects that your api works this way. I guess you see the trap. Therefor I use a readme where I explicitly define in which cases I use which status code. This doesn't mean that I use some random definion. I always try to use the standard but to avoid such cases I document my usage. The client might think you are wrong in some specific cases but as it is documented, there is no need for additional discussions what saves time for you and the developer.

One sentence to the Ops question: 404 is a code that always comes in my mind when I think back about starting to develop backend-applications and I configured something wrong in my controller-route so that my Controller method is not called. With that in mind, I think if the request does reach your code in a Controller method, the client did a valid request and the request endpoint was found. So this is an indication not to use 404. If the db query returns not found, I return 200 but with an empty body.

根据w3的帖子，

200好了

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

202年接受

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

204无内容

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

400错误请求

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

401年未经授权

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

404未找到

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