REST -扩展关系

  • 本文关键字:关系 扩展 REST rest
  • 更新时间 :
  • 英文 :


我正在构建一个事件管理系统。该模式描述如下。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,这样,如果它们不满,客户端以后可以很容易地访问完整的资源。

我建议你从谷歌上阅读一些关于"rest投影"的内容,或者查看RESTful Cookbook。

最新更新