如何为在层次结构中占据不同位置的资源设计 URI？答案

【问题标题】：How to design URI for a resource that occupies different positions in a hierarchy?如何为在层次结构中占据不同位置的资源设计 URI？
【发布时间】：2010-12-15 05:02:10
【问题描述】：

当列表可以由不同的资源“拥有”时，表示列表资源的最佳方式是什么？

以典型的博客为例。

假设您有帖子、评论和用户。一个帖子有很多评论，一个用户是很多评论的作者。

您可能希望获取给定用户上下文中的评论列表（例如，该用户的评论历史记录）、给定帖子（例如该帖子上的所有 cmets）或可能只是所有评论、句点 (虽然这不太可能）。

您可以拥有三个不同的 URI：

/user/user_id/comments
/post/post_id/comments
/comments

这样好吗？我的理解是 URI 应该是幂等的。拥有一个 url 是否更“RESTful”： /cmets

并传递过滤参数？例如

/comments?user=user_id
/comments?post=post_id

我猜这第二种方法意味着您也可以按用户过滤和发布与

/comments?user=user_id&post=post_id

但我喜欢第一个示例如何公开分层上下文。

这里的最佳做法是什么？

【问题讨论】：

标签： url rest friendly-url

【解决方案1】：

我的理解是 URI 应该是幂等的。

URI 不是操作，因此不能被描述为幂等的。幂等性只是意味着如果您进行两次相同的操作，则系统的最终状态与您进行一次操作相同。另一方面，URI 上的 HTTP 请求可以是幂等的，但并非所有请求都必须如此。例如，HTTP PUT 和 DELETE 应该始终是幂等的，但 HTTP POST 可能是也可能不是。 HTTP GET 根本不应该改变系统的状态。

对于友好的 URI 设计（与 REST 相切），我的建议是对感觉像查询的事物使用查询参数；通常是一些更大的资源集的子选择，例如分页和/或搜索。在这种情况下，/user/{user_id}/comments 完全可以。但是，我建议不要在 URI 中公开数据库键；这是您应该隐藏的实现细节，以确保 URI 在以后的日期超出当前实现时不会更改。对于像 user_id 值这样的东西，最好使用其他一些唯一值，比如那里的用户名。

【讨论】：

【解决方案2】：

在我看来，您的第一个示例在这两个示例中更好。不要忘记更重要的一点，即您的服务应该可以通过链接数据导航。因此，如果我要转到 /user/123，那么我会看到一个指向 /user/123/comments 的链接 [href, a]，它告诉我另一部分服务位于该 URI。

【讨论】：