3 回答
TA贡献1783条经验 获得超4个赞
制作一组单独的/memberships/
资源。
如果没有别的话,REST就是要制作可进化的系统。此时,您可能只关心某个玩家是否在某个特定团队中,但在将来的某个时刻,您会希望用更多数据来注释该关系:他们在该团队中待了多长时间,谁引用了他们对那个团队,他们的教练是谁/当时在那个团队等等。
REST依赖于缓存效率,这需要考虑缓存原子性和失效。如果您将新实体POST到
/teams/3/players/
该列表将失效,但您不希望备用URL/players/5/teams/
保持缓存状态。是的,不同的缓存将包含不同年龄的每个列表的副本,并且我们无法做很多事情,但我们至少可以通过限制我们需要使实体无效的实体数量来最小化用户POST更新的混淆在他们的客户端的本地缓存中唯一一个在/memberships/98745
(见“交替指数”的埃兰的讨论生命超越分布式事务的更详细的讨论)。您可以通过简单地选择
/players/5/teams
或/teams/3/players
(但不是两者)来实现上述2点。让我们假设前者。但是,在某些时候,您需要保留当前成员资格/players/5/teams/
的列表,并且能够在某处引用过去的成员资格。让超链接到列表中的资源,然后你可以添加当你喜欢,而不必打破大家的书签为个人会员资源。这是一般概念; 我相信你可以想象其他类似的期货更适用于你的具体情况。/players/5/memberships/
/memberships/{id}/
/players/5/past_memberships/
TA贡献1909条经验 获得超7个赞
我会将这种关系映射到子资源,一般设计/遍历将是:
# team resource/teams/{teamId}# players resource/players/{playerId}# teams/players subresource/teams/{teamId}/players/{playerId}
在Restful-terms中,它有很多不用考虑SQL和连接,而是更多地考虑集合,子集合和遍历。
一些例子:
# getting player 3 who is on team 1# or simply checking whether player 3 is on that team (200 vs. 404)GET /teams/1/players/3# getting player 3 who is also on team 3GET /teams/3/players/3# adding player 3 also to team 2PUT /teams/2/players/3# getting all teams of player 3GET /players/3/teams# withdraw player 3 from team 1 (appeared drunk before match)DELETE /teams/1/players/3# team 1 found a replacement, who is not registered in league yetPOST /players# from payload you get back the id, now place it officially to team 1PUT /teams/1/players/44
如你所见,我没有使用POST将球员放到球队,而是PUT,它可以更好地处理球员和球队的n:n关系。
添加回答
举报