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
The primary or most-commonly-used HTTP verbs (or methods, as they are properly called) are POST, GET, PUT, PATCH, and DELETE. These correspond to create, read, update, and delete (or CRUD) operations, respectively.
The most common are: GET, POST, PUT, and DELETE, but there are several others. There is no limit to the number of methods that can be defined and this allows for future methods to be specified without breaking existing infrastructure. The concept of idempotence is relevant to this discussion.
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:
GET
and POST
, taking their cues from HTML's <form>
element.GET
, PUT
, POST
and DELETE
. These take their cues from CRUD and RPC-pretending-to-be-REST type APIs.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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With