Ayende @ Rahien

Refunds available at head office

REST and Urls

Rob Conery has been talking about REST lately, and I think he perpetuate a common misconception. In particular, in the post I referenced, he is asking about ideas for URLs for doing things like logging in, working with productions and episodes, etc.

The problem with that is that this has very little to do with REST. Now, I’ll be the first that will tell you that discussions about architectural purity bore me, and I really like the concept of nice URLs. But nice URLs are totally different from REST.

These slides do a really good work of describing what REST is and how to work with it.

It wasn’t until I actually was called to do a code review on an application written by Rob Eisenberg that I really got it. That application was a pretty simple UI (well, the UI logic was simple, the UI itself was pretty complex, but that was mostly because of the visualizations). The interesting thing is that most of the UI was completely driven by the response from the server.

What I mean by that is that when you loaded an entity, it would load the appropriate view, and use information like this:

<link method="DELETE" title="Cancel" rel="rels/cancelOrder" href="/orders/1234"/>
<link method="GET" title="Shipping Details" rel="rels/viewShipping" href="/orders/1234/shipping"/>

To generate much of the actual behavior on the client side.

The client was fairly stable, but modifying the server meant that you could get a lot more from the system.

Human readable and hackable urls are nice, sure. But they have very little to do with REST.

Comments

Vitaly Stakhov
03/05/2012 08:26 AM by
Vitaly Stakhov

Nice to see this post in your blog especially after the 'limit your abstractions' series.

I would also add (or restate you) that the presence of links in responses allows to move the workflow logic from being both on client and server to server only.

Felice Pollano
03/05/2012 09:02 AM by
Felice Pollano

It is nice to see the Eisenberg Effect propagating over HTTP too.

johannes
03/05/2012 10:33 AM by
johannes

I have read lately a nice book about it: Thomas Erl – SOA Design Patterns.

He basically distinguishes between Resourceful APIs and REST. I think pretty URLs is part of Resourceful APIs where REST is much more such as using the correct verbs for CRUD, etc.

johannes
03/05/2012 10:34 AM by
johannes

I have read lately a nice book about it: Thomas Erl – SOA Design Patterns.

He basically distinguishes between Resourceful APIs and REST. I think pretty URLs is part of Resourceful APIs where REST is much more such as using the correct verbs for CRUD, etc.

Curtis Schlak
03/05/2012 12:05 PM by
Curtis Schlak

Completely agree. I wrote a blog post recently about Rob's statement as the result of a twitter debate. I also wrote two posts on Fielding's ReST, http://curtis.schlak.com/2012/01/19/fieldings-rest.html and http://curtis.schlak.com/2012/01/23/hateoas-a-follow-up-to-rest-for-r33lz.html. Hope they help with others' understanding.

Sean Gough
03/05/2012 01:25 PM by
Sean Gough

Rob himself posted a very interesting reply -- http://devlicio.us/blogs/rob_eisenberg/archive/2012/03/05/alt-tekpub-rest.aspx

Josh
03/05/2012 08:45 PM by
Josh

And if you notice, the RavenDB service is callED "HTTP API", and NOT "REST API".

Sla
03/07/2012 04:56 AM by
Sla

Would be nice if you can write blog post explainig your vision of REST and some small examples. Thanks.

Hendry Luk
03/08/2012 10:35 AM by
Hendry Luk

Although nice in concept, i find that pure REST-driven UI navigation too limitting to be useful in practice. For a start, there is already a very well established implementation of this very idea of using documents to drive navigation, complete with the capability to embed rich UI logic and layouting (in addition to primitive transitional links), all fully driven by server responses. And they named this implementation HTML. The UI engine that inteprets this RESTful messages is called web-engine. Reimplementing REST-driven UI is getting really close to reinventing the HTML. I find that driving your client navigation with REST with the absence of HTML/css/js capability usuallly poses a very restricting limitation in building a rich interactive UI (while also reduces chatiness), and i therefore abandoned this approach. In your example, for instance, how do you embed the logic of enabling your link buttons based on certain client-side conditions, purely using REST. Do u have any trick how you tackle this issue?

Comments have been closed on this topic.