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只是緩存鍵，僅此而已。

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

使其與帖子的URI保持一致。 假設您具有以下條件；

/posts返回所有帖子的鏈接
/posts/tags讀取所有帖子的標簽
/posts/id閱讀帖子
/posts/id/tags讀取/posts/id/tags的標簽

/blogs返回所有博客的鏈接
/blogs/id閱讀博客

現在，如果您想閱讀屬於博客的所有帖子的標簽，則可以將URI鏈接在一起；

/blogs/id/posts/tags讀取屬於博客的所有帖子的標簽。