我正在调用一个后端REST端点，它接受一个查询参数并搜索匹配的结果/people?name=joe，我想知道当在DB中没有找到匹配name=joe的对象时，我应该返回什么状态代码和返回数据。
我考虑过的事情：
- 如果我直接命中端点
/people/joe并且没有找到它，那么我肯定会返回404。 - 如果我遇到了一个返回查询结果列表的端点，比如
/people?name=joe应该返回所有名为joe的人，那么我只会返回200，并以空列表作为主体。但在我的例子中，每个名字只能有一个对象，所以我没有返回列表，所以这在这里不适用。
所以这是一个不同的例子，我点击了一个端点，并传递了一个查询参数来“搜索”一些数据。在很多情况下，数据可能还不存在。这看起来和上面的第一个要点非常相似，但我不喜欢在这里返回404，因为这不一定是一个错误。
我是否应该返回一个200，但以一个空对象{}作为主体，然后我的前端应该检查body == {}是否意味着没有找到数据？
或者我应该在这里返回一个404吗？同样，这在我的例子中并不是一个真正的错误，这就是为什么我不想使用404，但是如果这是最有意义的，那么我可以。
2条答案
按热度按时间bxjv4tth1#
在
GET请求的上下文中（它请求资源的当前选择的表示），200响应指示响应内容是资源的表示（例如，与错误的表示相对）。此外，URI是不透明的：通用的HTTP组件不会根据资源标识符的拼写对资源的语义做出假设。换句话说，两者的“规则”完全相同
因此，在HTTP级别，您的问题的答案很容易：如果存在当前表示，则使用
200状态回复GET请求，并将当前表示复制到响应内容中。困难的部分是决定什么时候有一个当前的表示，以及它看起来像什么。REST和HTTP对此没有什么可说的，真的。这是一个资源设计问题。
例如，这是“遵循所有规则”的交互：
第一次
HTTP是一种用于请求文档/通过网络传输文档的通用机制，但它不知道文档看起来像什么，以及我们使用什么键来标识存储中的文档。
如果您处理的是描述零个或正好一个事物的表示，那么使用空的或正好包含一个元素的列表仍然是合理的（如果您熟悉Option/Optional/Maybe：同样的想法，我们用可迭代集合的语义来表示一些东西）
第一个
hgqdbh6s2#
我同意在你的场景中200和空集合比404好。我不喜欢寻找
{}的想法，它不够明确。可能的方法：