在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.我使用 http://tools.ietf.org/html/draft-snell-link -方法作为我的实现参考.

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

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

I found that there are three types of clients:

1. 那些仅支持GET和POST的用户，它们的引用来自HTML的<form>元素.
2. 仅支持GET，PUT，POST和DELETE的那些.这些来自CRUD和RPC假装为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)覆盖方法，然后在后端Palm上使用我的post()函数转到适用于预期的HTTP方法的适当功能.这样，将来处于上述类2中的任何将来的客户端都可以使用PUT和DELETE，但可以将PATCH，LINK和UNLINK包装在POST请求中.您可以两全其美:支持它的客户端提供了丰富的方法，但仍然通过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屋！