REST風格的收藏和控制會員詳細信息

我幾次遇到過這個問題，每次我做一個沒有結果的搜索來想出滿意的答案。REST風格的收藏和控制會員詳細信息

我們有一個集合資源，它返回成員URI的表示以及具有相同URI（和自定義關係類型）的Link標題字段。通常我們發現我們需要集合中每個成員的具體數據。

在一個極端，我們可以讓收集只返回成員URI;客戶端必須依次查詢每個URI，以確定每個成員所需的數據。
在另一個極端，我們返回集合上我們想要的所有細節。這些都不是完美的;第一個可能會導致大量的API調用，第二個可能會返回大量可能不需要的信息。

在我們的案例中，我贊成第二種極端情況的兩種極端情況，因爲我們很少將這種情況用於一種以上的情況。然而，對於更一般的方法，我想知道是否有人有一個很好的方式來動態指定集合中每個成員應包含哪些細節？我猜一個查詢字符串參數是最合適的，但我不想打破資源的自描述性。

來源

2011-04-05 cmbuckley

聽起來像你試圖重塑PROPFIND（RFC 4918, Section 9.1）。

來源

2011-04-12 10:18:00

謝謝 - 這正是我所尋找的;我沒有考慮過尋找WebDAV。 – cmbuckley 2011-04-13 12:25:41

我經常在集合資源中的每個項目中包含元素的子集。你如何定義不同的子集真的取決於你。無論你做什麼，

/mycollectionwithjustlinks 
/mycollectionwithsubsetA 
/mycollectionwithsubsetB

，或者你使用查詢字符串

/mycollection?itemfields=foo,bar,baz

無論哪種方式，他們都是不同的資源。我不確定爲什麼你認爲這會影響自我描述的約束。

來源

2011-04-06 00:18:14

也許我的問題更多的是關於這些資源的_discoverability_。我理想地喜歡/ mycollection資源向客戶端指示它可以從中選擇的可用項目字段。 – cmbuckley 2011-04-06 09:12:07

@cbuckley您的集合可能包含一個特殊的ItemTemplate元素，其中包含可包含的可用字段列表。 – 2011-04-06 11:01:49

我不認爲它屬於身體，除非客戶要求提供這些信息。我可以使用自定義響應標題來標識它們，但這確實會破壞自描述性。我提出的最好的一個參數是Content-Type，即Content-Type：application/json;字符集= UTF-8;骨料= FOO，酒吧，baz'。客戶端然後將使用「Accept」標頭字段。 – cmbuckley 2011-04-07 08:22:06

我喜歡你的第一個選項..

在一個極端，我們可以有收集任何回報，但成員的URI;那麼客戶端必須依次查詢每個URI，以確定來自每個成員的所需數據。

如果您想通過線路減少HTTP調用的數量，例如從手機應用（iOS/Android）調用服務。您可以包括一個額外的頭，包括兒童資源：

X-Aggregate-Resources-Depth: 2

你的服務器端代碼必須將資源聚集到所需深度。

來源

2011-04-12 08:50:07 Easen

REST風格的收藏和控制會員詳細信息

回答

相關問題