架构 REST：如何设计用于请求 + 批准、2 个资源或 1 个资源的 REST API？

Question

假设您正在为需要批准的系统创建 REST API，例如组成员身份系统（我能想到的最接近的类比）。

我的会员资源是/membership. 我可以看到 3 种可能性：

A. 单一资源。

所以一个新的请求是POST /api/membership创建{group: 10, user:1, status:"pending"}. 然后组织管理员批准PATCH /api/membership/:membership {status: "member"}

优点：单一 API。缺点：更难轻松区分不同的成员类型；毕竟，“待定”成员并不是真正的成员。更重要的是，加入请求实际上并不是会员资格。

B. 分离资源。

一个新请求是POST /api/join创建一个加入请求{group: 10, user: 1, status:"pending"}。组织管理员然后由 批准PATCH /api/join/:join {status: "approved"}。然后自动（在服务器上）在/api/membership/:membership.

优点：将加入请求与实际会员资格完全分开。缺点：似乎是多余的（请求和成员资格的属性相似），并且依赖于在后端自动处理一种资源与另一种资源。

C. 分离资源和请求。

就像选项 B 一样，除了组织管理员分2 个步骤批准。先POST /api/membership {group:10, user:1}然后PATCH /api/join/:join {status:"approved"}。

优点：将请求与实际成员资格完全分开。也不依赖于一种资源的后台处理来影响另一种资源。缺点：依靠 UI 来做更麻烦！

帮助？

Answer 1

我会将其作为两个单独的资源来处理。会员申请和会员资格是两个不同的事情。此外，它们现在可能碰巧具有非常相似的属性，但如果它们在未来发生分歧，您就会陷入困境。我会做

POST /membership-requests
{
   "memberId": 7,
   "groupId": 15
}

创建请求。管理员可以做

GET /membership-requests?groupId=15&status=pending

按组获取请求，然后

PUT /membership-requests/12345
{
    "status": "approved"
}

批准请求。您可以使用服务器端业务逻辑来检测状态更改并创建成员资格。然后，该 PUT 可以返回指向成员资格的链接：

{
    "memberId": 7,
    "groupId": 15,
    "status": "approved",
    "membership": "/memberships/298"
}

如果您这样做，您的业务逻辑需要确保只有挂起的请求可以更改其状态。

如果您只使用一种资源，您将如何处理被拒绝的成员资格？对我来说，做一个没有意义的

GET /memberships?status=rejected

因为如果请求被拒绝，那就不是真正的会员资格。