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
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.
It is nice to see the Eisenberg Effect propagating over HTTP too.
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.
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.
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.
Rob himself posted a very interesting reply -- http://devlicio.us/blogs/rob_eisenberg/archive/2012/03/05/alt-tekpub-rest.aspx
And if you notice, the RavenDB service is callED "HTTP API", and NOT "REST API".
Would be nice if you can write blog post explainig your vision of REST and some small examples. Thanks.
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?
Comment preview