我目前正在实施一个REST API。 我有大量的个体资源之间的关系的资源模型。
我的问题是：你如何链接两个现有资源的情况下（建立关系）以RESTful的方式？
我碰到的一个解决方案是使用LINK和UNLINK HTTP动词。 该API消费者将能够使用链接LINK和下面的URI两种资源：/资源1 /：ID1 /资源2 /：ID2。
这种解决方案的问题是缺乏对LINK和UNLINK动词支持。 无论http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html或http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol提动词，他们似乎在很大程度上是“被遗忘”。 然而，原有的RFC 2068并指出它们的存在。
我真的很喜欢这个解决方案。 然而，恐怕很多消费者API /客户端将无法应对的解决方案由于缺乏LINK / UNLINK支持。 这是一个可以接受的解决方案还是有在一个RESTful API连接现有资源更好和/或更优雅的解决方案？
谢谢
我使用LINK和UNLINK在我的（定制，公司内部）的Web应用程序。 我用http://tools.ietf.org/html/draft-snell-link-method作为我的实现参考。
我发现，有三种类型的客户端：
GET和POST ，从HTML的提取线索<form>元素。 GET ， PUT ， POST和DELETE 。 这些都需要从CRUD和他们的线索RPC-假装将要休息型的API。 PATCH作为一个正式的RFC增加的这些量，作为具有WebDAV的增长，虽然有时2类客户端支持PATCH太。 由于我们目前正在开发我们的客户在公司内部，我们没有这个问题，但我看着它并没有定义我的API之前考虑利弊，在情况下，我们也希望允许第三方客户端。 我的解决方案（因为我们需要支持HTML客户没有JavaScript反正）是允许POST通过提供一个重写方法_METHOD领域（ application/x-www-form-urlencoded ），然后有我的post()的后台功能端棕榈关闭以用于预期HTTP方法相应的功能。 这样的话，在未来的任何客户端，能够在，比方说，上述2类，可以使用PUT和DELETE ，但包裹PATCH ， LINK和UNLINK在POST请求。 你得到两全其美：丰富的方法从支持它的客户，并仍然通过POST隧道支持低质量的客户。
