如何管理 REST API 中 3 个资源之间的关系 [英] How to manage relationship between 3 resources in REST API

查看:16
本文介绍了如何管理 REST API 中 3 个资源之间的关系的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在创建一个基于 REST 概念的 API,但在谈论相关资源时我仍然有些困惑.

I'm creating an API based on REST concept but I'm still a bit confused talking about relating resources.

我有一个网站,人们可以在其中注册多个群组并选择多个角色.例如,让我们以在公司注册的人作为场景:

I've a website where people can signup in multiple groups and choose multiple roles. For example let's take people that signup in companies as scenario:

公司

  1. 脸书
  2. 谷歌
  3. 苹果

角色

  • 营销
  • 销售
  • 开发
  • 客户支持

因此,当我想在具有某些角色的新公司中创建用户时,我会将类似的内容传递到/users 端点的 POST 请求中

So, when I want to create a user in a new company with certain roles, I would pass something like this into a POST request to /users endpoint

{
       "username" : "raffaele.izzia",
        "email"   : "example@email.com",
        "groups"  : [{
          "id" : 1,
          "roles" : ["Sales","Customer support"]
        },
        {
          "id" : 2,
          "roles" : ["Sales","Marketing"]
        }]
}

通过这种方法,一旦我从 API 中获得了一些用户,我总是知道他们在哪些组/角色中.

With this approach, once I get some users from the API I always know in which groups/roles they are.

但是/groups 端点上的请求呢?

But what about requests on /groups endpoint?

如果我 GET/groups/google 我也应该收到有关用户/角色的信息.所以它可能是这样的

If I GET /groups/google I should receive info about users/roles too. So it could be something like this

{ 
    groups: [{
        "id" : 2,
        "name"   : "Google",
        "users"  : [2,3,4,10,35,50] //role will be included in the single resource once you expand this collection
    }]
}

或者这个:

{ 
    groups: [{
        "id" : 2,
        "name"   : "Google",
        "roles"  : [{
           "name"  : "Sales"
           "users" : [2,3,4,10]
        },{
           "name"  : "Marketing"
           "users" : [4,10,8,57]
        }]
    }]
}

您认为这种关系的最佳解决方案是什么?

What do you think is the best solution for this kind of relationships?

推荐答案

这是个好问题.绝对是一个棘手的情况.

This is a good question. Definitely a tricky situation.

我认为典型的 RESTful 答案是根据名词(AKA 资源)进行思考.即使您将这种三向连接视为名词之间的关系,连接本身也是一个名词.这就是您希望 REST API 公开的内容.

I think the typical RESTful answer would be to think in terms of nouns, AKA resources. Even though you view this 3-way connection as a relationship between nouns, the connection itself is a noun. That's what you want your REST API to expose.

由于没有更好的术语,您的连接名称可能是分配(或分配,或其他).例如.Alice 在 Google 的市场营销部门工作"是一项任务.

For lack of a better term, perhaps the name for your connection is an assignment (or an allocation, or whatever). E.g. "Alice working for Google in Marketing" is an assignment.

这现在开辟了新的可能性,应该可以满足您的需求.

This now opens up new possibilities that should get you what you need.

例如一个赋值对象:

{
    "id": "...",
    "user": {...},  // e.g. Alice
    "group": {...}, // e.g. Google
    "role": "Marketing"
}

获取 /users/alice/assignments 会返回她所有作业的列表.

And fetching /users/alice/assignments returns a list of all of her assignments.

同样,获取 /groups/google/assignments 会返回 Google 工作人员的所有分配对象的列表.

Similarly, fetching /groups/google/assignments returns a list of all the assignment objects for people working at Google.

这样做的好处是现在您的作业确实是一流的.您现在可以执行诸如跟踪分配之类的事情,同时让您的主要 API 仅返回当前分配.等等(在此为这个答案提供灵感的道具.)

The advantage to this is that now your assignments are truly first-class. You can now do things like keep track of old assignments, while having your main APIs return only current ones. Etc. (Props to this answer for inspiration here.)

希望这会有所帮助!

这篇关于如何管理 REST API 中 3 个资源之间的关系的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆