用于获取嵌套对象字段的Rest设计

Question

假设我们下面有课

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

或者任何建议都可以。哪一个最受欢迎？

Answer 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：除了上面的内容，这意味着只有一个帖子，而不是一个集合。

Answer 2

哪一个最受欢迎？

休息不在乎您对资源标识符使用什么拼写，只要它们符合RFC 3986。机器并不关心--就它们而言，URI只是缓存键，仅此而已。

另见: Stefan Tilkov 休息:我觉得这不是你想的那样。

URI的拼写约定对人类很有用；它们很像变量命名约定，在给定的上下文中，我们重视熟悉性和一致性，而不是绝对地区分对错。

blogs/{blog-id}/posts/tags
blogs/{blog-id}/post/tags

检查数据库表命名的单数和复数参数可能是有用的。

blogs/{blog-id}/posts?field=tags
blogs/{blog-id}/post-tags
blogs/{blog-id}/posts/tags

选择后一种形式的一个原因是相对分辨率，特别是您可以使用点段来表示一个标识符和另一个标识符。

blogs/{blog-id}/posts/tags + ../images -> blogs/{blog-id}/posts/images

没有特别的理由认为tags段需要在posts下，甚至在blogs下--这个拼写也是“好的”，假设您不会遇到歧义性的问题：

/tags/{blog-id}

Answer 3

保持它与您为posts提供的URI保持一致。让我们假设你有以下几点；

/posts返回到所有帖子的链接

/posts/tags读取所有帖子的标记

/posts/id读一篇文章

/posts/id/tags读取帖子的标记

/blogs返回到所有博客的链接

/blogs/id读博客

现在，如果您想要读取属于一个博客的所有帖子的标签，那么将URI链接在一起是有意义的；

/blogs/id/posts/tags读取属于博客的所有帖子的标签。