如何处理 RESTful Web 服务中的聚合和组合

Question

我创建了以下实体，Book、Chapter 和 Feedback。 Book 有许多 Chapter 实体，它也有许多 Feedback 实体。由于没有Chapter 实体可以靠它们自己生活，它们是Book 组合的一部分。这同样适用于Feedback 实体。

我的问题是，作为组合一部分的对象是否应该在 RESTful 系统中拥有自己的 URI？如：

/books/1/chapters (With POST, DELETE, PUT operations) 
/books/1/feedback (With POST, DELETE, PUT operations)

还是应该像这样受到威胁：

/books/1 (With POST, DELETE, PUT operations only on the book)

最后一个 URI 意味着 API 的用户必须向图书数组添加反馈，然后更新整个图书实体。

由于章节不属于任何其他对象并且它们的生命周期依赖于书籍，因此将书籍和章节之间的关系称为“组合+聚合”是否有意义？

Answer 1

我的问题是，作为组合一部分的对象是否应该在 RESTful 系统中拥有自己的 URI

是的，绝对是。当实体表示的特定部分可独立寻址时，它显着更容易访问和管理这些部分。与其要求客户每次都检索整个表示，只是更新其中的一小部分，他们可以只关注需要修改的一个部分。它还极大地简化了访问控制，其中某些端点可能对特定调用者可用，但对其他调用者不可用。

定义子资源 URI 时要保留的一个约束是它们始终在其父资源的范围内定义（正如您在示例中已经展示的那样）。

并且将书籍和章节之间的关系称为“组合+聚合”是否有意义，因为章节不属于任何其他对象并且它们的生命周期取决于书籍

将关系称为组合是有意义的。聚合意味着子资源 (chapter) 可以存在于其父资源 (book) 的范围之外，在这种情况下它不能。聚合的示例类似于地址，它可以与 person 或 organization 相关联。