如何處理RESTful Web服務中的聚合和組合

我已經創建了以下實體Book,Chapter和Feedback。 Book有許多Chapter實體，它也有許多Feedback實體。由於沒有Chapter實體可以靠自己生活，所以它們是Book構圖的一部分。這同樣適用於Feedback實體。如何處理RESTful Web服務中的聚合和組合

我的問題是作爲組成部分的對象是否應該在RESTful系統中擁有自己的URI？如：

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

還是應threated這樣的：

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

最後一個URI意味着API的用戶將不得不反饋添加到本書的數組，然後更新整個圖書實體。

因爲章節不屬於任何其他對象，並且它們的生命週期取決於書本，所以稱作書籍和章節「組合+聚合」之間的關係是否合理？

來源

2013-04-20 LuckyLuke

明確地去找第一個選項。否則，如果你正在做本書的REST，那麼你需要將整本書放入其中以添加其他反饋。這是要傳輸的數據量很大;並且它還具有更多的併發更新隱含的含義。 – skirsch 2013-04-20 10:44:31

我的問題是，是一個組成部分對象是否應該有自己的URI在RESTful系統

是，最肯定。這使得顯着更容易訪問和管理實體表示的特定部分時，這些部分是獨立可尋址的。而不是要求客戶每次檢索整個表示，只是更新其中的小部分，他們可以只關注需要修改的部分。它也極大地簡化了訪問控制，其中某些端點可能對特定的呼叫者可用，但對其他呼叫者不可用。

定義子資源URI時需要保留的一個約束是，它們總是在其父資源的範圍內定義的（正如您在示例中已經顯示的那樣）。

而且它是有意義的調用之間的書籍和章節「組成+聚合」，因爲章不屬於任何其他對象，其生命週期的關係取決於書

這使得意思是指組成的關係。彙總將意味着子資源（章節）可能存在於其父項範圍之外（本書），在這種情況下它不能。聚合的例子可以是地址，其可以與人或組織相關聯。

來源

2013-04-20 10:41:33 Perception

太棒了，謝謝:) – LuckyLuke 2013-04-20 13:50:40

Up voteed。我的官方項目也面臨類似的情況，我試圖說服人們遵循這種方法來管理實體的特定部分，而不是處理。這有助於在提供細粒度控制的同時保持較低的網絡流量。 – 2015-06-03 09:06:07

如何處理RESTful Web服務中的聚合和組合

回答

相關問題