如何在 RESTful API 中处理多对多关系？

Question

假设您有两个实体，玩家和团队，其中玩家可以属于多个团队。在我的数据模型中，每个实体都有一个表，还有一个用于维护关系的连接表。 Hibernate 可以很好地处理这个问题，但是我如何在 < 中公开这种关系href="https://en.wikipedia.org/wiki/Representational_state_transfer#RESTful_web_services" rel="noreferrer">RESTful API？

我可以想出几种方法。首先，我可能让每个实体都包含另一个实体的列表，因此 Player 对象将具有它所属的 Teams 列表，并且每个 Team 对象将具有属于它的 Players 列表。因此，要将玩家添加到团队中，您只需将玩家的代表 POST 到端点，例如 POST /player 或 POST /team ，并使用适当的对象作为请求的负载。这对我来说似乎是最“RESTful”的，但感觉有点奇怪。

/api/team/0:

{
    name: 'Boston Celtics',
    logo: '/img/Celtics.png',
    players: [
        '/api/player/20',
        '/api/player/5',
        '/api/player/34'
    ]
}

/api/player/20:

{
    pk: 20,
    name: 'Ray Allen',
    birth: '1975-07-20T02:00:00Z',
    team: '/api/team/0'
}

我能想到的另一种方法是将这种关系本身作为一种资源公开。因此，要查看给定团队中所有玩家的列表，您可以执行 GET /playerteam/team/{id} 或类似操作，并获取 PlayerTeam 实体列表。要将玩家添加到团队中，请使用适当构建的 PlayerTeam 实体作为有效负载进行 POST /playerteam 。

/api/team/0:

{
    name: 'Boston Celtics',
    logo: '/img/Celtics.png'
}

/api/player/20:

{
    pk: 20,
    name: 'Ray Allen',
    birth: '1975-07-20T02:00:00Z',
    team: '/api/team/0'
}

/api/player/team/0/:

[
    '/api/player/20',
    '/api/player/5',
    '/api/player/34'
]

对此的最佳实践是什么？

Answer 1

我知道这个问题有一个标记为已接受的答案，但是，我们可以通过以下方式解决之前提出的问题：

以 PUT

PUT    /membership/{collection}/{instance}/{collection}/{instance}/

为例，以下内容都将产生相同的效果，而无需同步，因为它们在单个资源上完成：

PUT    /membership/teams/team1/players/player1/
PUT    /membership/players/player1/teams/team1/

现在，如果我们想要更新一个团队的多个成员资格，我们可以执行以下操作（经过适当的验证）：

PUT    /membership/teams/team1/

{
    membership: [
        {
            teamId: "team1"
            playerId: "player1"
        },
        {
            teamId: "team1"
            playerId: "player2"
        },
        ...
    ]
}

Answer 2

1. /players （是主资源）
2. /teams/{id}/players （是关系资源，因此它的反应与 1）
3. /memberships （是关系但语义复杂）
4. /players/memberships （是关系但语义复杂） ）

我更喜欢2

Answer 3

创建一组单独的 /memberships/ 资源。

1. 如果没有别的，REST 就是关于创建可进化的系统。此时，您可能只关心某个特定的玩家在某个特定的团队中，但在未来的某个时刻，您会想要用更多数据来注释这种关系：他们加入了多长时间在该团队中，谁将他们推荐给该团队，他们的教练在该团队中是谁，等等。REST
2. 依赖于缓存来提高效率，这需要考虑缓存原子性和失效。如果您将新实体发布到 /teams/3/players/，该列表将会失效，但您不希望备用 URL /players/5/teams/保持缓存。是的，不同的缓存将拥有不同年龄的每个列表的副本，对此我们无能为力，但我们至少可以通过限制需要无效的实体数量来最大程度地减少用户发布更新的混乱在其客户端的本地缓存中，只有一个，位于 /memberships/98745（请参阅 Helland 在 分布式事务之外的生活以获取更详细的讨论）。
3. 您只需选择 /players/5/teams 或 /teams/3/players（但不能同时选择两者）即可实现上述两点。我们假设是前者。然而，在某些时候，您可能希望保留 /players/5/teams/ 作为当前会员资格列表，但又能够参考过去的会员资格 某处的会员资格。将 /players/5/memberships/ 制作为 /memberships/{id}/ 资源的超链接列表，然后您可以添加 /players/5/past_memberships / 当您愿意时，无需破坏每个人对个人会员资源的书签。这是一个一般概念；我相信您可以想象其他更适合您的具体情况的类似未来。

Answer 4

在 RESTful 接口中，您可以通过将这些关系编码为链接来返回描述资源之间关系的文档。因此，一个团队可以说拥有一个文档资源 (/team/{id}/players)，它是指向球员的链接列表 (/player/{id}) >）在团队中，玩家可以拥有一个文档资源（/player/{id}/teams），它是指向该玩家所属团队的链接列表。漂亮又对称。您可以轻松地对该列表进行地图操作，甚至可以为某个关系提供自己的 ID（可以说它们有两个 ID，具体取决于您是考虑团队优先还是玩家优先的关系），如果这会让事情变得更容易。唯一棘手的一点是，如果您从一端删除关系，则必须记住从另一端删除该关系，但要通过使用底层数据模型严格处理此问题，然后让 REST 接口成为该模型将使这变得更容易。

关系 ID 可能应该基于 UUID 或同样长且随机的东西，无论您为团队和玩家使用什么类型的 ID。这样您就可以使用相同的 UUID 作为关系两端的 ID 组件，而不必担心冲突（小整数不有这个优势）。如果这些成员关系除了以双向方式关联球员和球队这一事实之外还具有任何属性，那么它们应该拥有独立于球员和球队的自己的身份；然后，玩家»团队视图 (/player/{playerID}/teams/{teamID}) 上的 GET 可以执行 HTTP 重定向到双向视图 (/memberships/{uuid}< /代码>）。

我建议使用 XLink< 在您返回的任何 XML 文档中编写链接（当然，如果您碰巧生成 XML） /a> xlink:href 属性。

Answer 5

我会将这种关系与子资源进行映射，一般设计/遍历将是：

# team resource
/teams/{teamId}

# players resource
/players/{playerId}

# teams/players subresource
/teams/{teamId}/players/{playerId}

用 RESTful 术语来说，它有助于不考虑 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 3
GET /teams/3/players/3

# adding player 3 also to team 2
PUT /teams/2/players/3

# getting all teams of player 3
GET /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 yet
POST /players
# from payload you get back the id, now place it officially to team 1
PUT /teams/1/players/44

如您所见，我不使用 POST 将玩家分配到团队中，而是使用 PUT，它可以更好地处理玩家和团队之间的 n:n 关系。

Answer 6

我的首选解决方案是创建三个资源：Players、Teams 和 TeamsPlayers。

因此，要获取一支球队的所有球员，只需转到 Teams 资源并通过调用 GET /Teams/{teamId}/Players 获取其所有球员。

另一方面，要获取玩家参加过的所有球队，请获取 Players 中的 Teams 资源。调用GET /Players/{playerId}/Teams。

并且，要获取多对多关系，请调用 GET /Players/{playerId}/TeamsPlayers 或 GET /Teams/{teamId}/TeamsPlayers。

请注意，在此解决方案中，当您调用 GET /Players/{playerId}/Teams 时，您将获得一组 Teams 资源，这与您获得的资源完全相同当您调用 GET /Teams/{teamId} 时。反之亦然，调用GET /Teams/{teamId}/Players时会得到一个Players资源数组。

在这两个调用中，都不会返回有关关系的信息。例如，不返回contractStartDate，因为返回的资源没有关于关系的信息，只有关于它自己的资源的信息。

要处理 nn 关系，请调用 GET /Players/{playerId}/TeamsPlayers 或 GET /Teams/{teamId}/TeamsPlayers。这些调用返回准确的资源，TeamsPlayers。

此 TeamsPlayers 资源具有 id、playerId、teamId 属性以及其他一些用于描述关系的属性。此外，它还有处理这些问题所需的方法。 GET、POST、PUT、DELETE 等将返回、包含、更新、删除关系资源。

TeamsPlayers 资源实现一些查询，例如 GET /TeamsPlayers?player={playerId} 以返回由 标识的玩家的所有 TeamsPlayers 关系{playerId} 有。按照同样的思路，使用 GET /TeamsPlayers?team={teamId} 返回所有在 {teamId} 队伍中比赛过的 TeamsPlayers 。
在任一 GET 调用中，都会返回资源 TeamsPlayers。返回与该关系相关的所有数据。

当调用 GET /Players/{playerId}/Teams （或 GET /Teams/{teamId}/Players）时，资源 Players （或Teams）调用 TeamsPlayers 使用查询过滤器返回相关团队（或玩家）。

GET /Players/{playerId}/Teams 的工作方式如下：

1. 查找玩家拥有id =playerId的所有TeamsPlayers。 (GET /TeamsPlayers?player={playerId})
2. 循环返回的TeamsPlayers
3. 使用从TeamsPlayers获取的teamId，调用GET /Teams/{teamId}并存储返回的数据
4. 循环结束后。返回所有参与循环的团队。

在调用 GET /Teams/{teamId}/Players 时，您可以使用相同的算法获取团队中的所有玩家，但交换团队和玩家。

我的资源将如下所示：

/api/Teams/1:
{
    id: 1
    name: 'Vasco da Gama',
    logo: '/img/Vascao.png',
}

/api/Players/10:
{
    id: 10,
    name: 'Roberto Dinamite',
    birth: '1954-04-13T00:00:00Z',
}

/api/TeamsPlayers/100
{
    id: 100,
    playerId: 10,
    teamId: 1,
    contractStartDate: '1971-11-25T00:00:00Z',
}

该解决方案仅依赖于 REST 资源。尽管可能需要一些额外的调用才能从球员、球队或其关系中获取数据，但所有 HTTP 方法都很容易实现。 POST、PUT、DELETE 简单明了。

每当创建、更新或删除关系时，Players 和 Teams 资源都会自动更新。

Answer 7

现有的答案没有解释一致性和幂等性的作用 - 这促使他们推荐 UUID/ID 的随机数和 PUT 而不是发布。

如果我们考虑这样一个简单的场景，例如“向团队添加新玩家”，我们就会遇到一致性问题。

因为播放器不存在，所以我们需要：

POST /players { "Name": "Murray" } //=> 201 /players/5
POST /teams/1/players/5

但是，如果在 POST 到 /players 后客户端操作失败，我们会创建一个不存在的播放器属于一个团队：

POST /players { "Name": "Murray" } //=> 201 /players/5
// *client failure*
// *client retries naively*
POST /players { "Name": "Murray" } //=> 201 /players/6
POST /teams/1/players/6

现在我们在 /players/5 中有一个孤立的重复玩家。

为了解决这个问题，我们可以编写自定义恢复代码来检查与某些自然键（例如Name）匹配的孤立玩家。这是需要测试的自定义代码，需要花费更多的金钱和时间等。

为了避免需要自定义恢复代码，我们可以实现 PUT 而不是 POST。

来自 RFC：

PUT 的意图是幂等的

对于幂等的操作，它需要排除外部数据，例如服务器生成的 id 序列。这就是为什么人们同时推荐 PUT 和 UUID 作为 Id 的原因。

这使我们能够重新运行 /players PUT 和 /memberships PUT 而不会产生任何后果：

PUT /players/23lkrjrqwlej { "Name": "Murray" } //=> 200 OK
// *client failure*
// *client YOLOs*
PUT /players/23lkrjrqwlej { "Name": "Murray" } //=> 200 OK
PUT /teams/1/players/23lkrjrqwlej

一切都很好，我们不需要做任何事情，只需重试部分失败即可。

这更多的是对现有答案的补充，但我希望它能将它们置于 ReST 的灵活性和可靠性的大背景中。