根据微软:控制器动作返回类型在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响应的最佳选项)我找到了资源，逻辑被执行了，我有一些内容给你，好好使用它，哦，顺便说一下，如果你要在视图中共享这个，请刷新视图以显示它。

希望能有所帮助。

我不认为404是正确的回应。

如果使用404，如何知道是没有找到api，还是数据库中的记录没有找到?

从你的描述，我会使用200 OK，因为你的api执行所有逻辑没有任何问题。只是在数据库中找不到记录。所以，这不是API问题，也不是数据库问题，这是你的问题，你认为记录存在，但它不存在。因此，API执行成功，数据库查询执行成功，但没有发现任何返回。

因此，在这种情况下，我会用

200好了

使用空响应，如数组的[]或对象的{}。

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

这样的事情可能是主观的，双方都有一些有趣和各种扎实的论点。然而，(在我看来)为丢失的数据返回404是不正确的。这里有一个简单的描述来说明这一点:

请求:能给我一些数据吗? 资源(API端点):我将在这里为您获取请求[发送潜在数据的响应]

没有问题，找到了端点，找到了表和列，因此查询了DB，并“成功”返回了数据!

现在，无论“成功响应”是否有数据都不重要，您要求“潜在”数据的响应，并且具有“潜在”数据的响应得到了满足。Null，空等是有效的数据。

200只代表我们的请求成功了。我正在请求数据，HTTP/REST没有任何问题，作为数据(尽管为空)返回我的“数据请求”是成功的。

返回一个200，让请求者在每个特定场景下处理空数据!

想想这个例子:

请求:查询用户ID为1234的“违规”表 资源(API端点):返回一个响应，但数据为空

此数据为空是完全有效的。这意味着用户没有违规行为。这是200，因为它是有效的，然后我可以这样做:

你没有违规，吃个蓝莓松饼!

如果你认为这是404，你在说什么?无法发现用户的违规行为?从语法上讲，这是正确的，但在REST世界中，成功或失败是关于请求的，这是不正确的。该用户的“违规”数据可以成功找到，没有违规-一个实数代表有效状态。

(厚颜无耻的注意。)

在你的标题中，你下意识地认为200是正确的回答:

对于有效请求但空数据，正确的REST响应代码是什么?

在选择使用哪种状态码时，抛开主观性和棘手的选择，以下是一些需要考虑的事情:

一致性。如果您使用404表示“无数据”，则在每次响应返回无数据时使用它。 同一个状态不要有多个意思。如果在没有找到资源时返回404(例如API端点不存在等)，那么也不要因为没有返回数据而使用它。这只会让应对反应变成一种痛苦。 仔细考虑上下文。什么是“请求”?你说你想达到什么目的?

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

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

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

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

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

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