REST API設計 - 集合爲陣列，ETag的

Question

採取以下網址範本：

~/pupil/{id}/subjects 

如果對象是在傳統的方式代表的集合，就像每個項目單獨屹立瞳孔項目，然後是這是揭露他們的正確方法嗎？

它開始當你考慮在學生方面，並同時與其他API調用者更新集合覺得不妥。

突然，因爲沒有ETag的覆蓋集和你最終交織的變化和糾結讓你無法同步訪問。

不同的設計可以看到結合作爲在光瞳的實體的子陣列的對象和/subjects URL僅僅是讀訪問。

也許這些主體應該作爲一個單獨的數組集合實體返回一個謹慎的ETag，並且應該禁用POST單個主題並且通過整個集合的POST/PUT進行更新，但是如果列表很長？需要分頁？

也許設計決策是逐的情況下，沒有一個徹底的方針。不確定。

想法？

Answer 1

這取決於你是否要正確對待「科目」作爲一個單一的資源或沒有。

如果像你說的，你的API中去的消費者要添加，刪除或修改個別科目的話，是代表他們是正確的關於REST模式的傳統方式：

~/pupil/{id}/subjects 

將在

~/pupil/{id}/subjects/{subjectId} 

返回的資源列表，除非有強有力的理由來優化批量操作或高速緩存，這是最REST風格的和直接的實現。