如何处理RESTful Web服务中的聚合和组合 [英] How to deal with aggregation and composition in RESTful web service

问题描述

我创建了以下实体，预订，章和反馈。 Book 有许多章实体，它还有很多反馈实体。由于没有章实体可以自己生活，因此它们是 Book 组合的一部分。这同样适用于反馈权利。

I have created the following entities, Book, Chapter and Feedback. The Book have many Chapter entities, and it also have many Feedback entities. Since no Chapter entities could live by them self they are part of the Book composition. The same applies to the Feedback entitiy.

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

My question is whether objects that are part of an composition should have their own URIs in a RESTful system? Such as:

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

或者它应该像这样被威胁：

Or should it be threated like this:

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

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

The last URI mean that the users of the API would have to add a feedback to an array of the book and then update the whole book entity.

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

And does it make sense to call the relationship between books and chapters "composition + aggregation" since chapters doesn't belong to any other object and their life cycle is dependent of book?

推荐答案

我的问题是作为作品一部分的对象是否应该有自己的URI RESTful系统

My question is whether objects that are part of an composition should have their own URIs in a RESTful system

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

Yes, most definitely. It makes it significantly easier to access and manage specific parts of the entity representation when those parts are independently addressable. Rather than requiring clients to retrieve the whole representation each time just too update small portions of it, they can focus on just the one part that needs to be modified. It also greatly simplifies access control, where certain endpoints may be available to particular callers but not too others.

定义子资源URI时要保留的一个约束是它们总是在父资源的范围内定义（正如您在示例中所示）。

The one constraint to be kept when defining sub-resource URI's is that they always be defined within the scope of their parent resource (as you are already showing in your example).

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

And does it make sense to call the relationship between books and chapters "composition + aggregation" since chapters doesn't belong to any other object and their life cycle is dependent of book

将关系称为组合是有意义的。聚合意味着子资源（章节）可能存在于其父级（ book ）的范围之外，在这种情况下它不能。聚合的示例可以是地址，可以与人或组织相关联。

It makes sense to refer to the relationship as composition. Aggregation would mean that the sub-resource (chapter) could exist outside the scope of its parent (book), which in this case it cannot. An example of an aggregation would be something like an address, which could be associated to a person, or an organization.

这篇关于如何处理RESTful Web服务中的聚合和组合的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！