一對多關聯REST API

Question

我們在API設計中存在一點模棱兩可的問題，特別是一對多關聯。

場景：

學生 - 擁有衆多 - 圖書（一對多）

應如何API看看書分配給student？預期的行爲是從現有的中刪除一些並向現有的添加新的。

[POST] /students/1234/books - 不允許的（如書籍可以分配給其他用戶以後可能適合於支持票和評論的場景。）

[PUT] /students/1234/books - 從實際的觀點REST API點，它是修改該集合比集合內的實體。

現有的學生書籍：[{id:1, name:’REST1’, author:’Satish’, year:2003}, {id:2, name:’REST2’, author:’Satish’ , year:2003}]

修改學生書籍：[{id:2, name:’REST2’, author:’Satish’ , year:2003}, {id:3, name:’REST3’, author:’Satish’ , year:2003}] - 一個刪除和一個新增加的。

現在這個功能可以通過只發送book id列表來實現，如下所示。但這更多的是一種行動，而不是資源導向。另一方面，發送用於映射的書籍對象列表對於移動客戶端查看可用帶寬來說將非常繁重。

請求負載：[1, 2, 4]

是否有適應於行業這樣問題的做法？

Answer 1

概念上，書本身也是資源，所以你應該代表它們。雖然網址並不重要，但我可能像這樣的事情：

*/book/1 
*/book/2 
... 

基本上，如果你有任何的表示的任何「標識」，這幾乎是一個安全的賭注，這些應該是資源本身。

從那裏你可能會決定代表與書籍的關係，作爲單獨的資源。我認爲這是一種「所有權」關係，儘管從你的描述中不完全清楚。因此，學生將有：

*/student/1234/ownedbook/111 
*/student/1234/ownedbook/112 
... 

有可能是支持張貼一本新書URL擁有，GET獲得的擁有書籍的完整列表聚集資源，並投入修改資書一氣呵成。當然，刪除上面的所有權鏈接之一將刪除只有該書的所有權，而不是書本身。

所有權的表示可能是書本身的單一URL，甚至不必是json的東西。所有權的綜合表示是一個簡單的URL列表。

如果您想要看起來很漂亮，您可以決定使用ATOM來維護所有權列表，這樣您可以包含更多信息（不僅僅是URL），因此您可以更輕鬆地顯示時間（因爲您不需要「不得不拉出每本書來找出標題，作者等來顯示）。

要點是，代表一切「重要」作爲資源，他們應該通過URL而不是通過ID引用彼此。你至少有三件重要的事情：書籍，學生，所有權關係。其他的一切，比如URL的外觀，無論是json還是xml，都不是那麼重要。