我们希望在多个客户端上创建一个屏幕,显示" 5畅销产品"," 5最近添加的产品"和" 5产品提供优惠"。所有这些都将显示为旋转木马。
我们想为这些创建Restful API。我们创建了以下API:
目前,每个客户端,即桌面,移动,android,ios都对这些URI进行了硬编码。我担心如果我们明天更改这些URL,它会很麻烦,而且REST建议" REST客户端通过一个简单的固定URL进入REST应用程序。 (参考:https://en.wikipedia.org/wiki/HATEOAS)"
在这种情况下,有人可以建议我如何确保所有客户通过简单的固定网址进入应用程序?
答案 0 :(得分:1)
在HATEOAS中,URI是可发现的(并且没有记录),因此可以更改它们。也就是说,除非它们是您系统的入口点(Cool URIs,唯一可以由客户进行硬编码的入口点) - 如果您希望能够进化,那么您不应该有太多的入口点将来系统的其他URI结构。这实际上是REST的useful最多功能之一。
对于剩余的非酷URI,它们可以随着时间的推移而改变,并且您的API文档应该说明应该在运行时通过超媒体遍历发现它们。
查看Richardson's Maturity Model (level 3),这将是链接发挥作用的地方。例如,从顶级,例如/ api / version(/ 1),您会发现有一个指向组的链接。以下是HAL Browser等工具的外观:
根:
{
"_links": {
"self": {
"href": "/api/root"
},
"api:bestsellingproduct": {
"href": "http://apiname:port/api/bestsellingproduct"
},
"api:recentlyaddedproduct": {
"href": "http://apiname:port/api/recentlyaddedproduct"
},
"api:greatofferproduct": {
"href": "http://apiname:port/api/greatofferproduct")
}
}
}
这里的优点是客户端只需要知道关系(链接)名称(显然除了资源结构/属性),而服务器大多可以自由地改变关系(和资源)URL。
你甚至可以将它们嵌入到同一个root api调用中返回:
{
"_embedded": {
"bestsellingproduct": [
{
"id": "1",
"name": "prod test"
},
{
"id": "2",
"name": "prod test 2"
}
],
"recentlyaddedproduct": [
{
"id": "3",
"name": "prod test 3"
},
{
"id": "5",
"name": "prod test 5"
}
]
}