具有跨资源视图的 REST API 架构设计 [英] architectural design for REST API with views across resources

问题描述

寻找有关 REST API 架构设计的一些意见.我经常发现所需的数据是跨多个资源的视图的组合.您希望客户将它们组合起来，还是提供一个 API 来为客户进行组合?

Looking for some input on a REST API architectural design. I often find that the desired data is the combination of a view across multiple resources. Would you expect the client to combine them, or provide an API that does the combination for the client?

例如，假设我们正在编写一个 REST API，让人们收到有关事件的通知.有人会通过以下两种方式之一表示对某项活动感兴趣:

For example, let's say we are writing a REST API for people to become notified about events. Someone will indicate interest in an event in one of 2 ways:

• 加入一个定期举办个人感兴趣的活动的组织
• 搜索并标记由我通常不会订阅的组织举办的特定活动

通过执行以下长步骤，我可以检索用户 100 的所有事件:

I can retrieve all of the events for user 100 by doing the following long steps:

1. GET/user/100/organizations 返回 123
2. GET/organizations/123/events 返回 [15,16,20]
3. GET/user/100/savedevents 返回 [35,36]
4. GET/events/15,16,20,35,36 返回所有事件

1. GET /user/100/organizations returns 123
2. GET /organizations/123/events returns [15,16,20]
3. GET /user/100/savedevents returns [35,36]
4. GET /events/15,16,20,35,36 returns all of the events

但这对客户来说似乎相当沉重.我几乎希望客户能够说，给我这个用​​户的所有有趣事件":

But that seems rather heavy for a client. I almost want a client to be able to say, "give me all of the interesting events for this user":

GET /user/100/events

...然后要求服务器理解它必须完成所有步骤 1-4 并返回它们，或者至少返回 [15,16,20,35,36] 所以它变成了 2 个步骤:获取事件 ID；获取活动详情.

...and then require the server to understand that it has to go through all of steps 1-4 and return them, or, at the very least, return [15,16,20,35,36] so it becomes 2 steps: get event IDs; get event details.

以这种方式创建跨越多个资源的视图是否有意义?

Does this even make sense, to make a view that cuts across multiple resources that way?

进一步解释.我的犹豫是因为我可以看到 /organizations/123/events 是一个干净的资源；if 等同于说 /events?organizations=123，即给我资源事件，其中组织 =123"./user/100/organizations 也一样.

To explain further. My hesitation is because I can see how /organizations/123/events is a clean resource; if is identical to saying /events?organizations=123, i.e. "give me resource events where organizations=123". Same for /user/100/organizations.

但是 /user/100/events 是不是给我组织=123 的资源事件".它是在 user=100 处为我提供组织注册，检索这些组织 ID，然后在组织 =123 处为我提供事件，然后在 user=100 处为我提供保存的事件."

But /user/100/events is not "give me resource events where organizations=123". It is "give me organizations registrations where user=100, retrieve those organization ids, then give me the events where the organization=123, then give me savedevents where user=100."

这三个步骤中的每一个本身都是一个干净的资源映射.把它们放在一起看起来很混乱.但是要求客户端(尤其是 Web 客户端)弄清楚所有这些逻辑也是如此！

Each of the three steps itself is a clean resource mapping. Putting them together seems messy. But so does asking a client (especially a Web client), to figure out all that logic!

推荐答案

可能有几种方法可以解决这个问题...但是，我认为大多数时候(如果服务由同一个提供者管理)它是最好在服务器端拥有逻辑并使 REST 调用尽可能相互独立(即，服务器执行所需的多个操作 - 通常从存储在 API 资源中处理的数据的数据库读取数据).

There may be several ways to solve this... however, I think that most of the times (if the service is managed by the same provider) it is better to have the logic on the server-side and make REST calls as independent as possible of each other (i.e., the server performing the multiple operations required - normally read data from DBs that are store the data handled in the API resources).

在您谈论的示例中，您的 REST API 将公开他感兴趣的用户"资源和子资源事件"(您称之为保存的事件").考虑到这一点，您将有像这样:

In the example you talk about this would mean your REST API would expose a "user" resource and a sub-resource "events" (which you call "savedevents") he is interested in. With this in mind you would have something like this:

• POST/user/{username}/events 存储用户感兴趣的新事件(或多个事件)
• GET/user/{username}/events 返回用户感兴趣的所有事件
• GET/user/{username}/events/{eventid} 返回特定事件的详细信息

• POST /user/{username}/events stores a new event (or multiple events) the user is interested in
• GET /user/{username}/events returns all the events the user is interested in
• GET /user/{username}/events/{eventid} returns details of a specific event

要过滤"每个组织的用户事件(和其他过滤操作)，您可以使用查询参数":

To "filter" user events per organization (and other filtering operations) you can use "query parameters":

• GET/user/{username}/events?organization=123

因此，服务器(或 API 调用)将执行您在 GET/user/{username}/events 中从步骤 1 到步骤 4 描述的操作.您仍然可以在 API 中创建其他资源(组织"和事件")，但它们将用于其他上下文(例如存储新事件或组织等).

So, the server (or API call) would perform the operations you describe from step 1 to step 4 in the GET /user/{username}/events. You can still make the other resources ("organizations" and "events") in your API, however they would be used in other contexts (like store new events or organizations, etc.).

HTH

这篇关于具有跨资源视图的 REST API 架构设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！