在开发一些REST api时，我遇到了一个逻辑问题，对此我没有明确的答案。
假设我正在开发一个API，用户可以使用它从后端(例如对象存储)检索一些数据。
通常API返回status code 200，对象被转移给用户。
但是，如果请求的对象不存在，API应该返回什么错误代码?
这里有两个可能的解决方案:
- 返回
200，因为它代表API功能本身，工作良好，并在响应体中出现消息错误，其中写有404 file not found - 返回
404，因为无法检索到文件
应该遵循什么标准?从逻辑上讲，我认为2是最明显的答案，但是我看到像Elasticsearch这样的产品表现得像1。
我从声称#1应该是正确的人那里得到的解释是，状态码应该代表API本身的功能，并且当API按预期工作时，它返回200，但是找不到对象。
我从声称第2条的人那里得到的解释是，返回200只是误导，他们不在乎API是否工作良好，好像它不会工作良好，它只会在某些时候给50x错误。
在你看来应该遵循什么逻辑?有什么标准可以参考吗?
多谢!
假设我正在开发一个API，用户可以使用它从后端(例如对象存储)检索一些数据。
重要思想:你的资源模型和你的数据模型不一样。 HTTP关心的是资源和资源的表示。您可以查看RFC 9110以获得对资源的解释，但查看Roy Fielding的定义可能更有用:然而，如果请求的对象不存在，API应该返回什么错误代码?
任何可以命名的信息都可以是资源:文档或图像，时间服务(例如"洛杉矶今天的天气")，其他资源的集合，非虚拟对象(例如人)，等等。换句话说，任何可能成为作者超文本引用目标的概念都必须符合资源的定义。
如果你想到不同种类的"资源"我们经常在网上访问(网页、图片、样式表、脚本)。我的建议是从"文档"的概念开始，但要认识到资源的概念可以更通用。
现在，HTTP响应中的状态码是通过网络域传输文档的元数据。元数据的受众是web上通用HTTP组件(浏览器、缓存、爬虫等)的集合。
除其他事项外，状态码的使用提供了关于HTTP响应携带的有效负载的提示:它是资源的表示形式吗?而是对错误的解释?如果你把一个文本文档想象成一个资源，很明显，该文档的内容可以是任何东西，包括与错误消息无法区分的字符序列(我们得到一个错误消息，将其保存为文件，现在从我们的web服务器提供该文件)。服务器通过使用成功状态码(2xx)向外界传递这些字节实际上是来自文件的数据。
HTTP GET是我们用来获取资源当前表示形式的方法。但是资源是否具有当前表示，以及如何确定，都是隐藏在统一HTTP接口后面的实现细节。
事实上，你的后端存储没有与从你的资源标识符计算出的键匹配的对象，这可能意味着相应的资源根本没有表示(4xx)，或者它可能意味着资源有一个"空白";表示(无论以何种方式，空白在您的资源模型中是有意义的)。
这里没有一个唯一的正确答案，因为所有的资源模型都不一样;我们不是根据什么是"最佳"来选择发送哪种HTTP响应，而是根据什么是"最适合"来选择发送哪种HTTP响应。对于我们正在使用的交互模型(即使在同一资源模型中，也可能从一个资源更改为另一个资源)。