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

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

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

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

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

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

我得说，两者都不太合适。 正如@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服务器从自己的作用域提供的信息:即，是否发现服务在处理请求。

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

如果期望资源存在，但它可能是空的，我认为它可能更容易得到一个200 OK的表示，表明这个东西是空的。

因此，我宁愿让/things返回一个带有{"Items":[]}的200 OK，而不是一个没有任何内容的204，因为这样，一个包含0项的集合可以被视为一个包含一个或多个项目的集合。

我将把204 No Content留给put和delete，在这种情况下，可能真的没有有用的表示。

在/thing/9不存在的情况下，404是合适的。

使用公共枚举对响应内容进行编码，以允许客户端打开它并相应地派生逻辑。我不知道你的客户如何区分“数据未找到”404和“网络资源未找到”404之间的区别?您不希望有人浏览到userZ/9，并让客户端怀疑请求是否有效，但没有返回数据。

这个话题中的答案(在撰写本文时已经有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端点不存在等)，那么也不要因为没有返回数据而使用它。这只会让应对反应变成一种痛苦。 仔细考虑上下文。什么是“请求”?你说你想达到什么目的?