在 REST API 中使用 LINK 和 UNLINK HTTP 动词 [英] Using LINK and UNLINK HTTP verbs in a REST API

问题描述

我目前正在致力于实现 REST API.我有一个资源模型，其中包含单个资源之间的大量关系.

I am currently working on implementing a REST API. I have a resource model with a large number of relationships between the individual resources.

我的问题是:如何以 RESTful 方式将两个现有资源相互链接(建立关系)?

My question is: how do you link two existing resources to each other (establishing a relationship) in a RESTful manner?

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

One solution I came across was the use of the LINK and UNLINK HTTP verbs. The API consumer would be able to link two resources using LINK and following 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 确实声明它们存在.

The problem with this solution is the lack of support for the LINK and UNLINK verbs. Neither http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html or http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol mention the verbs, and they seem to be largely "forgotten". However, the original RFC 2068 does state that they exist.

我真的很喜欢这个解决方案.但是，由于缺乏对 LINK/UNLINK 的支持，恐怕很多 API 使用者/客户端将无法处理该解决方案.这是一个可以接受的解决方案还是有任何更好和/或更优雅的解决方案来链接 RESTful API 中的现有资源?

I really like this solution. However, I'm afraid that many API consumers/clients will not be able to deal with the solution due to the lack of support for LINK/UNLINK. Is this an acceptable solution or are there any better and/or more elegant solutions for linking existing resources in a RESTful API?

谢谢

推荐答案

我在我的(定制的、公司内部的)Web 应用程序中使用 LINK 和 UNLINK.我使用 https://datatracker.ietf.org/doc/html/Draft-snell-link-method 作为我的实现参考.

I use LINK and UNLINK in my (bespoke, company-internal) web app. I use https://datatracker.ietf.org/doc/html/draft-snell-link-method as my implementation reference.

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

I found that there are three types of clients:

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

1. Those that only support GET and POST, taking their cues from HTML's <form> element.
2. Those that only support GET, PUT, POST and DELETE. These take their cues from CRUD and RPC-pretending-to-be-REST type APIs.
3. Those that allow any method. The publication of PATCH as an official RFC has increased the amount of these, as has the growth of WebDAV, although sometimes category 2 clients support PATCH too.

由于我们目前在内部开发我们的客户，所以我们没有这个问题，但我已经研究了这个问题，并且在定义我的 API 之前确实考虑了利弊，以防我们确实希望允许第三方客户.我的解决方案(因为我们需要在没有 Javascript 的情况下支持 HTML 客户端)是允许 POST 通过提供一个 _METHOD 字段(application/x-www-form-urlencoded)，然后将我的 post() 函数放在后端掌上，用于预期 HTTP 方法的适当函数.这样，将来任何属于上述第 2 类的客户端都可以使用 PUT 和 DELETE 但包装 PATCH、POST 请求中的 >LINK 和 UNLINK.您可以两全其美:来自支持它的客户端的丰富方法，但仍然通过 POST 隧道支持低质量的客户端.

Since we currently develop our clients in-house we don't have this problem, but I have looked into it and did consider the pros and cons before defining my API, in case we did want to allow third-party clients. My solution (since we needed to support HTML clients without Javascript anyway) was to allow POST to override the method by supplying a _METHOD field (application/x-www-form-urlencoded) and then have my post() function on the back-end palm off to the appropriate function for the intended HTTP method. That way, any client in the future that is in, say, class 2 above, can use PUT and DELETE but wrap PATCH, LINK and UNLINK in a POST request. You get the best of both worlds: rich methods from clients that support it, and yet still support low-quality clients through POST-tunnelling.

这篇关于在 REST API 中使用 LINK 和 UNLINK HTTP 动词的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！