api - 在 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在我的(定制的、公司内部的)网络应用程序中。我用https://datatracker.ietf.org/doc/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 方法的适当函数。这样，将来任何属于上述第 2 类的客户端都可以使用 PUT和DELETE但包装PATCH , LINK和UNLINK在 POST要求。您可以获得两全其美的好处:来自支持它的客户端的丰富方法，但仍然通过 POST 隧道支持低质量客户端。