假设我们下面有课
class Blog {
Integer id;
List<Post> posts;
}
class Post {
Integer id;
List<String> tags;
}
如果我想为某个博客的所有标签建立端点，那么什么是正确的选择。返回类型为List。
blogs/{blog-id}/posts?field=tags
blogs/{blog-id}/post-tags
blogs/{blog-id}/posts/tags
blogs/{blog-id}/post/tags
或者任何建议都可以。哪个最合适？
答案 0 :(得分：1)
根据您的使用情况，在您列出的列表中，我会选择第一个或第二个。
blogs/{blog-id}/posts?field=tags：这表明您只需要tags字段中的集合中的项目。我希望响应中每个帖子仍然有一个对象，但是只有tags字段存在。如果您想要一个不同的列表，则需要在客户端中进行处理。
blogs/{blog-id}/post-tags：这将用于返回一个单独的不同标签列表。
这就是为什么我不会和其他人一起去的原因：
blogs/{blog-id}/posts/tags：这可能会被视为标题为tags的帖子，而不是返回帖子中的所有标签。
blogs/{blog-id}/post/tags：除了上述内容之外，这还意味着仅发布一个帖子，而不是一个收藏集。
答案 1 :(得分：1)
哪个最合适？
REST不在乎您对资源标识符使用什么拼写，只要它们符合RFC 3986。这些机器不在乎-就它们而言，URI只是缓存键，仅此而已。
另请参阅：Stefan Tilkov REST: I Don't Think It Means What You Think It Does。
URI的拼写约定对人类很有用。它们很像变量命名约定，在这里我们重视给定上下文中的熟悉程度和一致性 ，对与错没有绝对的含义。
blogs/{blog-id}/posts/tags
blogs/{blog-id}/post/tags
查看database table naming的单数或复数参数可能很有用。
blogs/{blog-id}/posts?field=tags
blogs/{blog-id}/post-tags
blogs/{blog-id}/posts/tags
您可能更喜欢后一种形式的原因是relative resolution，尤其是您可以使用dot segments来表示另一个标识符的事实。
blogs/{blog-id}/posts/tags + ../images -> blogs/{blog-id}/posts/images
没有特别的原因，tags段必须在posts以下，甚至不需要在blogs以下-假设您不运行，此拼写也是“很好的”陷入模棱两可的问题：
/tags/{blog-id}
答案 2 :(得分：0)
使其与帖子的URI保持一致。假设您具有以下条件；
/posts返回所有帖子的链接
/posts/tags读取所有帖子的标签
/posts/id阅读帖子
/posts/id/tags读取帖子的标签
/blogs返回所有博客的链接
/blogs/id阅读博客
现在，如果您想阅读属于博客的所有帖子的标签，则可以将URI链接在一起；
/blogs/id/posts/tags读取属于博客的所有帖子的标签。