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,124 | Comments: 45,475

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: You want all the data, you can’t handle all the data - one day from now
  2. The design of RavenDB 4.0: Making Lucene reliable - about one day from now
  3. RavenDB 3.5 whirl wind tour: I’ll find who is taking my I/O bandwidth and they SHALL pay - 3 days from now
  4. The design of RavenDB 4.0: Physically segregating collections - 4 days from now
  5. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - 5 days from now

And 14 more posts are pending...

There are posts all the way to May 30, 2016


  1. RavenDB 3.5 whirl wind tour (14):
    29 Apr 2016 - A large cluster goes into a bar and order N^2 drinks
  2. The design of RavenDB 4.0 (13):
    28 Apr 2016 - The implications of the blittable format
  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