架构 REST:如何设计用于请求 + 批准、2 个资源或 1 个资源的 REST API? [英] Architectural REST: How do I design a REST API for request+approval, 2 resources or 1?

问题描述

假设您正在为需要批准的系统创建 REST API，例如一个团体会员制度(我能想到的最接近的比喻).

Let's say you are creating a REST API for a system that requires approval, e.g. a group membership system (closest analogy I can think of).

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

My resource for membership is /membership. I can see 3 possibilities:

A.单一资源.

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

So a new request is POST /api/membership which creates {group: 10, user:1, status:"pending"}. The org admin then approves by PATCH /api/membership/:membership {status: "member"}

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

Pro: single API. Con: Harder to easily differentiate between different member types; after all, a "pending" member isn't really a member. More importantly, a request to join isn't actually a membership.

B.单独的资源.

一个新请求是POST/api/join，它创建一个加入{group: 10, user: 1, status:"pending"} 的请求.然后组织管理员通过 PATCH/api/join/:join {status: "approved"} 批准.然后自动(在服务器上)在 /api/membership/:membership 创建另一个资源.

A new request is POST /api/join which creates a request to join {group: 10, user: 1, status:"pending"}. The org admin then approves by PATCH /api/join/:join {status: "approved"}. This then automatically (on the server) creates another resources at /api/membership/:membership.

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

Pro: Cleanly separates requests to join from actual memberships. Con: Seems redundant (the properties of a request and a membership are similar), and depends on automatically juggling one resource from another on the back-end.

C.将资源和请求分开.

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

Just like Option B, except that the org admin approves in 2 steps. First POST /api/membership {group:10, user:1} and then PATCH /api/join/:join {status:"approved"}.

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

Pro: Cleanly separates requests from actual memberships. Also does not rely on background processing of one resource to affect another. Con: Relying on the UI to do it is even messier!

帮助?

推荐答案

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

I would handle this as two separate resources. A membership request and a membership are two different things. In addition, they may happen to have very similar properties now, but if they diverge in the future you'll be stuck. I would do

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

创建请求.管理员可以做

to create the request. The admin could do

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

按组获取请求，然后

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

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

to approve the request. You could use server-side business logic to detect the status change and create the membership. That PUT could then return a link to the membership:

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

如果您这样做，您的业务逻辑需要确保只有待处理的请求可以更改其状态.

If you do this, your business logic needs to make sure that only pending requests can have their status changed.

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

If you only use one resource, how will you handle rejected memberships? To me, it doesn't make sense to do a

GET /memberships?status=rejected

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

because if the request is rejected, that's not really a membership.

这篇关于架构 REST:如何设计用于请求 + 批准、2 个资源或 1 个资源的 REST API?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！