Rickard Oberg is popular among Java developers. He has given seminars at all main Java conferences world wide. He worked as an architect at JBoss and other popular OpenSource Java frameworks, and wrote a book on RMI. In recent years, he has become famous as an Aspect Oriented Programming (AOP) crusader. He has worked with bleeding edge AOP in a portal product that has become a great commercial success, and is currently working on Qi4j at Jayway. Rickard is a DZone MVB and is not an employee of DZone and has posted 16 posts at DZone. You can read more from them at their website. View Full User Profile

REST and the Missing Link

10.19.2010
| 4371 views |
  • submit to reddit

This morning I was thinking some more about the topic in the previous post, and was also doing some refactoring of our client code to be more RESTish. I had some cases where previously I had been thinking along the "usual" way of doing things, and changing it to be more strict REST helped out a lot. In particular, I tried to find the missing links.

I'll give you an example. We have a lot of CRUDish operations that need to be done. In particular, we have selection lists, where a list of references to already created entities need to be maintained. In the old version I would first do a query for a list of possible entities that could be added to a list, which would return {id,name} tuples, that the user could select from. Then the client would create a link and post/put it to the server. Simple enough, but what if the REST API changes? Then the client would be trying to do something which is not allowed. Something was wrong.

The solution was to simply follow the REST constraints. The client would first query the resource itself that represents the list, then in that response see that a link to a query for "possibleEntities" (or somesuch) was available, and enable it in the UI. When the user clicks on the "Add" button/item in the UI the client would then perform the query. The client doesn't "know" how to construct this query, because all it has to do is do a GET on the provided link, whatever it is. The result would be a list of links, each with a name and a href (like HTML links, but encoded in JSON). The client would present the list, and the user could select from it. Once selected the client then simply takes the link and do a post or put on it. It doesn't know how to create the link itself, and doesn't have to.

This gives me as the REST API developer freedom to change how that link is constructed at any time, without impacting the client. Maybe it was "addstuff?id=123" or "/somelist/123" or something else, but as long as the client only knows that "posting to this link will add the item to the list", it's fine. I don't have to worry about "backwards compatibility" in terms of URL construction. Only if the link relationships change will there be compatibility issues.

And that's what I'm starting to get about properly doing REST, with hypertext as the driver of my client. It's all in the links. And that is why soooo many who claim they're doing REST really aren't, like the CouchDB example from the last post. They are missing the links. And by extension, they are missing the point about REST.

 

From http://www.jroller.com/rickard/entry/rest_and_the_missing_link

Published at DZone with permission of Rickard Oberg, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: