我们在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}] - 删除了一个，添加了一个新的。
现在，通过仅发送图书ID列表可以最好地实现此功能，如下所示。但这更像是一种行动而非资源导向。另一方面，发送用于映射的书籍对象列表对于移动客户端查看可用带宽非常重要。
请求有效负载： [1, 2, 4]
有没有针对此类问题在行业中采用的做法？
答案 0 :(得分：0)
从概念上讲，书籍本身也是资源，所以你应该代表它们。虽然URL并不重要，但我可能会想象这样的事情：
*/book/1
*/book/2
...
基本上，如果您在任何陈述中都有任何“ID”，那么几乎可以肯定这些资源本身应该是资源。
从那里你可能决定将书籍的关系表示为单独的资源。我认为这是一种“所有权”关系，尽管从你的描述中并不完全清楚。所以学生会有：
*/student/1234/ownedbook/111
*/student/1234/ownedbook/112
...
可能有一个聚合资源支持POST一个新书的URL来拥有，GET可以获得一个完整的自有书籍列表，PUT可以一次修改所拥有的书籍。当然删除上面的一个所有权链接会删除仅书籍的所有权而不是书本身。
所有权的表示可以是书本身的单个URL，甚至不必是json的东西。所有权的汇总表示是一个简单的URL列表。
如果您想获得幻想，可以决定使用ATOM来维护所有权列表，这样您就可以包含其他信息（而不仅仅是URL），这样您就可以更轻松地显示（因为你不必拉每本书来找出要显示的标题，作者等。
点是，表示作为资源的所有“重要”，它们应该通过URL而不是ID来引用彼此。你至少有三件重要的事情：书籍，学生，所有权关系。其他所有内容，例如URL的外观，无论是json还是xml，都不是那么重要。