在REST API中使用LINK和UNLINK HTTP谓词

Question

我目前正致力于实现REST API。我有一个资源模型，在各个资源之间有很多关系。

我的问题是：如何以RESTful方式将两个现有资源相互链接（建立关系）？

我遇到的一个解决方案是使用LINK和UNLINK HTTP动词。 API使用者可以使用LINK和以下URI链接两个资源：/ resource1 /：id1 / resource2 /：id2。

此解决方案的问题是缺少对LINK和UNLINK动词的支持。 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html或http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol都没有提到动词，而且它们似乎在很大程度上被“遗忘”了。但是，最初的RFC 2068确实声明它们存在。

我真的很喜欢这个解决方案。但是，由于缺乏对LINK / UNLINK的支持，我担心许多API消费者/客户将无法处理该解决方案。这是一个可接受的解决方案，还是有更好的和/或更优雅的解决方案来链接RESTful API中的现有资源？

由于

Answer 1

我在我的（定制的，公司内部的）网络应用中使用LINK和UNLINK。我使用http://tools.ietf.org/html/draft-snell-link-method作为我的实现参考。

我发现有三种类型的客户端：

1. 仅支持GET和POST的广告，从HTML的<form>元素中获取提示。
2. 仅支持GET，PUT，POST和DELETE的广告。这些提示来自CRUD和RPC假装成REST类型的API。
3. 允许任何方法的那些。 PATCH作为官方RFC的发布增加了这些数量，WebDAV的增长也是如此，尽管有时类别2客户也支持PATCH。

由于我们目前在内部开发我们的客户，我们没有这个问题，但我已经调查过并在定义我的API之前考虑了利弊，以防我们确实想要允许第三方客户。我的解决方案（因为我们需要支持没有Javascript的HTML客户端）是允许POST通过提供_METHOD字段（application/x-www-form-urlencoded）来覆盖该方法，然后让我的post()函数在后端掌上关闭到预期的HTTP方法的适当函数。这样，将来的任何客户都可以使用PUT和DELETE，但可以使用PATCH，LINK和UNLINK在POST请求中。您可以获得两全其美的优势：来自支持它的客户端的丰富方法，但仍然通过POST隧道支持低质量客户端。