子资源的API设计？

Question

我正在构建一个相当复杂的 Web API，但我有点困惑的是子资源的创建。

具体来说，从游戏的角度来思考，

一场比赛属于一轮，一轮属于一个赛季，一个赛季属于一场比赛。 在其父上下文之外，每个项目都没有相关性，但无论如何它们都是资源。

所以我想知道我的 url 模式应该是什么来创建游戏？

//full tree map
PUT /competitions/1/seasons/2/rounds/3/games

//each sub resource has it's own top level, but must be created under 
//it's parent
PUT /rounds/3/games 

//each sub resource has it's own top level, and we include the parent 
//id in the resource body.
PUT /games

我更喜欢/games 因为它是自己的顶层，因为它更深入，例如，游戏有一个统计数据，而一个统计数据有一个视频，所以处理完整的树形图可能会很繁重，也许我应该支持这三个吗？

Answer 1

一个典型的模式是使顶层成为资源的规范 URI，但允许 GET 离开完整的树。所以:

GET /competitions/1/seasons/2/rounds/3/games

GET /games
GET /games/12
PUT /games
    competition=1
    season=2
    round=3

您这样做的支持负担稍大。你确定值得吗？

GET /games?competition=1&season=2&round=3

也是有道理的。我希望比赛资源的部分响应是该比赛中各赛季的列表 URI。

我建议不要有多个支持 PUT、POST、PATCH 或 DELETE 的 URI。您的代码将很快成为令人头疼的支持问题。