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

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

  

哪个最合适？

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}

Answer 3

使其与帖子的URI保持一致。假设您具有以下条件；

/posts返回所有帖子的链接
/posts/tags读取所有帖子的标签
/posts/id阅读帖子
/posts/id/tags读取帖子的标签

/blogs返回所有博客的链接
/blogs/id阅读博客

现在，如果您想阅读属于博客的所有帖子的标签，则可以将URI链接在一起；

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