27

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

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

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.

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.

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?

Thanks

Jeroen Minnaert
  • 625
  • 1
  • 9
  • 19
  • 1
    Why not create a Link resource that links the two resources? –  Sep 03 '12 at 12:25
  • 3
    That's another solution I was considering (it's pretty much handled in this [SO question](http://stackoverflow.com/questions/6324547/how-to-handle-many-to-many-relationships-in-a-restful-api). However, the problem is that for every type of relation, you have to define a new resource(type). This overcomplicates the resource model and isn't particularly pragmatic (since your API consumer has to be aware of a lot more types of resources). LINK/UNLINK doesn't overcomplicate it: establishing a relationship is very predictable and thus easier to use. However, if LINK/UNLINK are hardly supported... – Jeroen Minnaert Sep 03 '12 at 12:37

1 Answers1

32

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. 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.

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.

Community
  • 1
  • 1
Nicholas Shanks
  • 10,623
  • 4
  • 56
  • 80
  • I completely agree with this answer. I ended up implementing it just this way back in september and I am glad someone else came to the same conclusion. Thanks! – Jeroen Minnaert Jul 08 '13 at 00:33