假设您正在为需要批准的系统创建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来做的甚至更麻烦！
帮助？
我将其作为两个单独的资源来处理。成员资格请求和成员资格是两个不同的事物。另外，它们现在可能恰好具有非常相似的属性，但是如果将来它们出现分歧，您将被困住。我会做
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
因为如果请求被拒绝，那实际上不是会员。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句