如何设计具有关系的 REST API 端点

Question

我正在设计一个 RESTful API，在为具有多对多关系的实体建模和实现端点时面临着挑战。

示例：

Role

表存储用户可以拥有的角色，例如“管理员”、“用户”、“主持人”等。

Permission

表存储各个权限，例如“create_post”、“edit_post”、“delete_post”、“comment”等。

User_Role

表在用户和角色之间建立了多对多关系，允许用户在需要时拥有多个角色。

Role_Permission

表在角色和权限之间建立了多对多的关系，允许角色拥有与其关联的特定权限。

对于

Role

和

Permission

我有以下模式：

POST /roles
GET /roles
GET /roles/[id]
PUT /roles/[id]
DELETE /roles/[id]

POST /permissions
GET /permissions
GET /permissions/[id]
PUT /permissions/[id]
DELETE /permissions/[id]

这两种关系的端点 URL 应该是什么样子？我的想法是：

Create a New Role-Permission Relationship:
POST /role_permissions

Delete an Existing Role-Permission Relationship:
DELETE /role_permissions/[id]

也许

/roles/[id]/permissions/[id]

也可以工作？

我想确保我的 API 设计干净、高效，并遵循最佳实践。

Answer 1

A

Role_Permission

没有自己的id，它通过角色的id和权限的id来标识。因此，

/role_permissions/[id]

不能作为端点。

您可以（并且应该）使用

GET /roles/[id]/permissions
PUT|PATCH /roles/[id]/permissions
POST /roles/[id]/permissions/
GET /roles/[id]/permissions/[id]
DELETE /roles/[id]/permissions/[id]

或

GET /permissions/[id]/roles
PUT|PATCH /permissions/[id]/roles
POST /permissions/[id]/roles
GET /permissions/[id]/roles/[id]
DELETE/permissions/[id]/roles/[id]

或者两者兼而有之。选择哪一个取决于您的领域：关系是定向的吗？一侧的基数是否比另一侧大得多？对于典型的“部分关系”（其中一个实体只是另一个实体的一部分），组合首先出现，成员其次。对于 has-a 关系，您通常会使用相同的顺序 - 在您的示例中，是 /roles/[id]/permissions 而不是

/permissions/[id]/roles

，并且

/users/[id]/roles

不是

/roles/[id]/users

。