我正在构建一个事件管理系统。该架构描述如下。 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
最佳答案
在另一个请求的正文中返回资源的完整表示并没有错。不过,正如您所提到的,这可能是冗长的。
鉴于该服务的某些调用者可能只希望返回 URI,但有时您希望减少网络上的往返次数,即,您希望在一次调用中获得所有内容,那么您正在搜索的术语是投影。
这些是满足客户需求的资源的不同表示。
您可以在 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 与您的投影一起返回,以便如果它们未满,客户端稍后可以轻松访问完整资源。
我建议你阅读谷歌的“休息预测”或查看 RESTful Cookbook。
关于REST - 扩展关系,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16172304/