Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,125 | Comments: 45,492

filter by tags archive

REST and Urls

time to read 2 min | 342 words

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.


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

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.

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

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.

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?

Comment preview

Comments have been closed on this topic.


  1. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 3 days from now
  2. The design of RavenDB 4.0: Voron has a one track mind - 4 days from now
  3. RavenDB 3.5 whirl wind tour: Digging deep into the internals - 5 days from now
  4. The design of RavenDB 4.0: Separation of indexes and documents - 6 days from now
  5. RavenDB 3.5 whirl wind tour: Deeper insights to indexing - 7 days from now

And 10 more posts are pending...

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    05 May 2016 - Physically segregating collections
  2. RavenDB 3.5 whirl wind tour (14):
    04 May 2016 - I’ll find who is taking my I/O bandwidth and they SHALL pay
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats