存在资源但不存在实体的正确 HTTP 状态代码？答案

【问题标题】：Correct HTTP status code for existent resource, but non-existent entity?存在资源但不存在实体的正确 HTTP 状态代码？
【发布时间】：2014-01-22 05:42:57
【问题描述】：

假设客户端正在请求以下 URL：

/user-details?user=123

如果/user-details 是不存在的资源，那么正确的状态码显然是404。

但是，如果 /user-details 确实存在，但不存在 ID 为 123 的用户：

到目前为止，我已经返回了 404 Not Found，但经验告诉我，不知道它是 resource 还是 entity 会让人感到困惑没有找到；
我考虑过使用400 Bad Request，但我也觉得它很混乱，因为请求在技术上是正确的，只是请求一个不存在的实体。

是否有更适合此目的的 HTTP 状态码？

【问题讨论】：

您是否有理由不愿意接受当前的答案之一？你最终使用了什么？
阅读下面的答案后，我认为 404 更好，我相信我还没有准备好接受它;)
http 应该只是扩展它们的规范以包含新代码，以便我们可以区分 404-resource-not-found 和 404-requested-entity(resource) -not-found。 404-1 或 404-a 或任何有效的方法。

标签： http http-status-codes

【解决方案1】：

404 很好，因为在这种情况下，用户详细信息资源是到用户实体到部分用户资源信息的概念映射。

因此，用户详细信息的 GET 方法不负责区分以下两种情况：a) 用户不存在，b) 用户详细信息不存在。

但是，我会将端点重写为这样的：

/user/123/details

在我看来更具表现力。

【讨论】：

【解决方案2】：

试试WebDav中使用的422？见http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

对我来说 404 状态也可以（实际上更规范），400 太模糊了。

【讨论】：

支持这个答案的有趣论据here：“具体来说，许多 API，如 Twitter 和 Recurly，正在使用 HTTP 扩展中定义的状态代码“422 Unprocessable Entity” WebDAV。"

【解决方案3】：

user 参数是RFC 3986, section 3.4 中所述的资源标识符的一部分：

查询组件包含非分层数据，以及路径组件（第 3.3 节）中的数据，用于识别 URI 方案和命名机构范围内的资源

因此，404/Not found 完全没问题。

【讨论】：

所以它是查询字符串而不是路径的一部分这一事实并不重要？你有任何链接到一些支持这个的资源吗？
我已更新我的答案以包含来自相关 RFC 的引用。
从 RESTful 的角度来看（如果是 REST API）查询字符串用于细化操作的结果，这与问号的使用是一致的。它应该用于 URI 路径映射到一组实体而不是单个实体的服务，例如/users?name=约翰。您通常会将 URI 视为标识资源的路径，例如 /users/123，它是 /user/123 的同义词。请记住，一些框架使用这种方法来映射请求，因此使用查询字符串来识别资源在这个意义上是有问题的。
@raspacorp 我明白你的意思，甚至会同意你在 ReST 中处理资源的问题。但是，我认为您缺少 URL 的一个重要特征：它们是 references 并且它们的身份不应与引用资源的身份相混淆。毕竟，它们是uniform，而不是unique 资源定位器。哦，顺便说一句：根据我的经验，通过 RESTful 路径表达的关系相当模棱两可。它可以是“has-a”或“is-subset-of”。后来一个完全适合你提到的精炼或结果操作。