我正在设计一个与 Facebook 中的帖子和评论功能相似的 REST API。
URI 看起来像：
/posts/{post-id}/comments/{comment-id}
为了获得所有评论，我使用集合 URI 命名标准。例如：
/posts/{post-id}/comments
但是当我需要对所有帖子发表评论时，我遇到了困难。记住我只想将此设计用于帖子和评论的最佳方式是什么？
我必须在这里提到，我使用的资源与帖子和评论有点不同，在我的设计中我将不得不使用帖子并且不能将评论作为完全不同的实体。很抱歉对于这个误会。
话虽如此，是否建议以以下任何一种方式设计 URI：
/posts//comments
/posts/"any-string"/comments
下面的 URI 应该服务于目的。
/注释
对于上面给出的示例，让我们了解实体和 URI 的关系：
帖子和评论本身就是两个实体。
当您只需要帖子并且只需要传递 post_id 时
要检索帖子：
/posts要检索特定帖子：
/posts/{post_id}
当您只需要评论并且只需要传递comment_id 时
要检索所有评论：
/comments要检索特定评论：
/comments/{comment_id}
当您需要通过同时传递 post_id 和 comment_id 对给定帖子发表评论时
要检索帖子的评论：
/posts/{post_id}/comments要检索给定帖子的特定评论：
/posts/{post_id}/comments/{comment_id}
希望它能解决你的问题。
但是当我需要对所有帖子发表评论时，我遇到了困难。记住我只想将此设计用于帖子和评论的最佳方式是什么？
HTTP 包含重定向的概念- 一种用于告诉客户端向其他资源发送请求的通用工具。
GET /714eeebd-d89e-4f13-b2a8-cf8a3ee03481 ...
307 Temporary Redirect
Location: /7604abf9-d4f5-42c7-b687-96dbff32649f
这意味着，如果您为 URI 选择了错误的拼写，您可以稍后更正它。
REST 的设计使得标识符是不透明的——除了服务器之外没有人应该从它们中提取信息。
另外，请记住，资源不是域实体——拥有比域对象多得多的资源是正常的。您的域模型中的任何给定 Post 都可能有许多不同的资源来显示它。
如果你真的在开发一个 REST 服务，并且你想通过让欺骗变得困难来“帮助”客户，你可能想放弃使用可破解标识符的想法。
说了这么多
/comments
本身就是一个完全合理的集合标识符，并且在该根下创建标识符层次结构是完全合理的。