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

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

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

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

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

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

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

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

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

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

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

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

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

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

想想这个例子:

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

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

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

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

(厚颜无耻的注意。)

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

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

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

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

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.

这里有两个问题。一个在标题中，一个在例子中。我认为，这在一定程度上导致了关于哪种反应是合适的争议。

问题标题询问空数据。空数据仍然是数据，但不等于没有数据。因此，这意味着请求一个结果集，即一个列表，可能来自/users。如果一个列表是空的，它仍然是一个列表，因此204(无内容)是最合适的。您刚刚请求了一个用户列表，并得到了一个列表，它只是碰巧没有内容。

相反，所提供的示例询问了一个特定的对象，一个用户/users/9。如果没有找到用户#9，则不返回任何用户对象。您请求一个特定的资源(一个用户对象)，但由于没有找到而没有得到它，因此404是合适的。

我认为解决这个问题的方法是，如果您可以在不添加任何条件语句的情况下使用响应，那么使用204，否则使用404。

在我的例子中，我可以迭代一个空列表而不检查它是否有内容，但是我不能在一个空对象上显示用户对象数据而不破坏一些东西或添加一个检查来查看它是否为空。

当然，如果适合您的需要，您可以使用空对象模式返回一个对象，但这是另一个线程的讨论。

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

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

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

1.—资源为:/users

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

so:

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

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

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

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

205:(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服务器从自己的作用域提供的信息:即，是否发现服务在处理请求。

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