RESTful更新资源超链接

我正在设计一个RESTful Web服务，并试图正确使用超媒体来建立资源之间的关系。对于某些资源，客户端需要能够将关系分配给另一个资源，但是在我看来，要求客户端生成超链接和POST/PUT/PATCH /无论这个超链接到资源中有什么缺点（更复杂对于客户端，安全和负载平衡问题等）。我在想让客户端发送一个简单的ID并让服务器生成URL会更好。RESTful更新资源超链接

以下是一些为钢琴租赁API设计的资源，用以展示我的想法。

GET http://company.com:9999/customers/42 
{ 
    "id"  : 42, 
    "name"  : "George P. Burdell", 
    "phone"  : "555-555-5555", 
    "piano"  : { "href" : "http://company.com:9999/pianos/101"} 
} 

GET http://company.com:9999/pianos/101 
{ 
    "id"  : 101, 
    "make"  : "Steinway", 
    "model"  : "Model D" 
}

假设客户想租一架不同的钢琴。

客户端发送一个部分更新，如：

PATCH http://company.com:9999/customers/42 
{ "piano" : 202}

服务器会再生成正确的URL到新的钢琴资源并相应更新：

GET http://company.com:9999/customers/42 
{ 
    "id"  : ..., 
    "name"  : ..., 
    "phone"  : ..., 
    "piano"  : { "href" : "http://company.com:9999/pianos/202"} 
}

编辑： 作为我看到它，客户直接更新超链接可能会有问题。这是一个RESTfully好的解决方案，还是有更好的解决方案？这甚至不是问题吗？此外，以某种方式更新资源超链接的客户的真实世界示例将非常棒 - 我还没有找到任何示例。

来源

2012-03-14 HolySamosa

我喜欢这个主意，它是干净和优雅，为所有实体所在内的，只要工作相同的REST webservice ...与所有API（不仅仅是REST风格的）一样，一个合适的文档是强制性的......我不是主打的：什么是你的问题/目标？ – Yahia 2012-03-14 16:44:20

谢谢，好点。直接更新超链接的客户似乎有问题，我正在寻找一个干净的解决方案或有人向我解释为什么这不是问题。当我开始输入问题时，上面的解决方案对我来说就是我决定抛出去征求意见。 – HolySamosa 2012-03-14 16:59:19

您的回复缺少RESTful系统HATEOAS contraint所需的链接和表单。例如，如果客户想要租用不同的钢琴，那么您可以在钢琴响应中添加一个“租金”表单。例如

GET http://company.com:9999/pianos/101 
{ 
    "self"  : "http://company.com:9999/pianos/101", 
    "id"  : 101, 
    "make"  : "Steinway", 
    "model"  : "Model D", 
    "rent"  : { 
     "href"  : "http://company.com:9999/pianos/101", 
     "method" : "post" 
     // you can add form parameters like from and to dates here 
    } 
}

IMO应该创建一个“出租”资源，这将提供钢琴和客户之间的多对多关系。然后，要让客户取消租赁，您可以在租赁协议中填写删除表单。

这里有一些好文章涉及这样的：

来源

2012-03-15 05:21:16

RESTful更新资源超链接

回答

相关问题