6

我正在构建一个事件管理系统。架构如下所述。API 理解这些关系并在请求结果中返回相关资源的链接。例如，

GET /Events/1

    "links": {
    "Venue": "/Venues/1",
    "Tickets": "/Tickets?event_id=1",
    "Teams": "/Teams?event_id=1",
    "Registrations": "/Registrations?event_id=1"
}

我读过的关于 REST 和 HATEOAS 的大部分内容都表明这是“正确”的做法，但效率非常低。例如，如果我想生成参与事件的用户和团队的报告，它需要许多请求。这类似于运行多个选择查询，而不是针对数据库运行单个连接查询。所以我的问题是，我应该扩展关系并将相关资源嵌入资源请求中吗？这也带来了一个问题，b/c 上面的请求将返回大量数据。答案可能是坚持使用关系链接并设置适当的缓存。无论如何，我想听听你的意见。

Schema

events
    hasMany registrations
    hasMany tickets
    hasMany teams

team
    belongsTo event

ticket
    belongsTo event
    hasMany registrations

user
    hasMany registrations

registrations
    belongsTo event
    belongsTo ticket
    belongsTo user
    belongsTo team
4

1 回答 1

6

在另一个请求的正文中返回资源的完整表示并没有错。正如您所提到的，这可能是冗长的。

鉴于服务的某些调用者可能只希望返回 URI，但有时您希望减少跨网络的往返次数，即您希望在一次调用中完成所有操作，您要搜索的术语是projections。

这些是满足客户需求的资源的不同表示形式。

您可以在 URI 参数中指定这些，例如，GET /Events/1?venueProjection=full,teamProjection=uri

然后根据客户的要求返回投影。

"links": {
"Venue": {
    "uri": "/Venues/1",
    "attr1": "value1",
    "attrN": "valueN"
},
"Tickets": "/Tickets?event_id=1",
"Teams": "/Teams?event_id=1",
"Registrations": "/Registrations?event_id=1"
}

注意：始终返回带有您的投影的 URI，这样，如果它们未满，客户端稍后可以轻松访问完整的资源。

我建议您阅读 Google 的“休息预测”或查看 RESTful Cookbook。

于 2013-04-23T15:30:28.157 回答