26

我目前正在实现一个 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 中的现有资源？

谢谢

4

1 回答 1

31

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

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

  1. 那些只支持GETandPOST的，从 HTML 的<form>元素中获取线索。
  2. 仅支持GET,PUT和POST的那些DELETE。这些从 CRUD 和 RPC-pretending-to-be-REST 类型的 API 中获取线索。
  3. 那些允许任何方法的。作为官方 RFC的发布PATCH增加了这些的数量，WebDAV 的增长也是如此，尽管有时第 2 类客户端PATCH也支持。

由于我们目前在内部开发我们的客户，我们没有这个问题，但我已经研究过了，并且在定义我的 API 之前确实考虑了利弊，以防我们确实想要允许第三方客户。我的解决方案（因为我们无论如何都需要支持没有 Javascript 的 HTML 客户端）是允许POST通过提供一个_METHOD字段 ( application/x-www-form-urlencoded) 来覆盖该方法，然后post()将后端手掌上的函数转移到预期 HTTP 方法的适当函数。这样，未来的任何客户端，例如上面的第 2 类，都可以使用PUTandDELETE但 wrap PATCH，LINK并且UNLINK在POST要求。你得到了两全其美：来自支持它的客户端的丰富方法，但仍然通过 POST 隧道支持低质量的客户端。

于 2013-06-10T09:09:08.800 回答