Enterprise Integration Zone is brought to you in partnership with:

Arnon Rotem-Gal-Oz is the director of technology research for Amdocs. Arnon has more than 20 years of experience developing, managing and architecting large distributed systems using varied platforms and technologies. Arnon is the author of SOA Patterns from Manning publications. Arnon is a DZone MVB and is not an employee of DZone and has posted 68 posts at DZone. You can read more from them at their website. View Full User Profile

REST – The Good, The Bad and The Ugly

  • submit to reddit

I recently got a request from Alik for my opinion on REST. I think  this might be interesting for a wider audience and decided to blog my answer here.

Note: I also have a REST presentation I prepared a while ago, which is downloadable from here (ppt)

The Good

As you probably know REST is an architectural style defined by Roy Fielding for the web which is built on several foundations (client/server, uniform interface etc.) which gives it a lot of strength in affected areas. The top three in my opinion are:

  • (relatively) Easy to integrate – a good RESTful API is discoverable from the initial URI onward. This doesn’t suggest that a any application calling on on your service will automagically know what to do. It does mean however that the developer reading your API trying to integrate it has an easier life. Esp. if since hypermedia provides you the roadmap of what to do next.
  • Another feature for ease of integration which has to do with REST over HTTP (THE most common implementation of REST ) is the use of ubiquitous standards. Speaking HTTP which is the protocol of the web, emitting JSON or ATOMPub means it is much easier to find a library that can connect to you on any language and platform.
  • Scalability – stateless communication, replicated repository make for a good scalability potential.

do note that, as with any architecture/technology – a bad implementation can negate all the benefits other REST goodness are things like the notion of the URI, idempotance of GET in  REST over HTTP etc.


The Bad

Some of the  problems of REST aren’t inherent problems of the architectural style but rather drawbacks of the REST over HTTP implementation. Most notable of these is what’s known as “lo-rest” (using just GET and POST) – While technically it might still be RESTful, to me a uniform interface with 2 verbs is too small to be really helpful (which indeed makes a lot of the implementation unRESTful see “The Ugly” below)

One problem which isn’t not HTTP specific is handling REST- programming languages are not resource oriented so the handling code that maps URIs to tends to get messy. Actually Microsoft did a relatively good work with implementing Joe Gregorio’s idea of URI mapping which helps alleviate  some of the problem. On the other hand it is relatively hard to make the REST API hyper-text driven (Which is a constraints of REST)

Lastly and most importantly REST is not the answer to everything (see also another post I made on using REST along with other architectural styles) – e.g. most REST implementations I know do not support the notion of pub/sub (Roy did suggest a REST implementation called WAKA that enables this but most people never even heard of it). be weary of the “Hammer” syndrome, REST is a good tool for your toolset but it isn’t the only one. 

The Ugly

In my opinion there are 2 main ugly sides for REST. The first is Zealots. That isn’t something unique to REST any good technology/idea (Agile, TDD etc. ) gets its share of followers who think that <insert favorite idea> is the best thing since sliced bread and that everybody should do as they do or else.

The real ugliness comes from the misusers – There’s a lot of mis-understanding. The fact that REST over HTTP has become synonymous with REST leads people to think that HTTP is REST. I recently read a REST book review on Colin’s blog where “the author states that although hypermedia is important in REST it isn't covered in the book because WCF has poor support for it” i.e. a book on REST which ignores one of the important constraints of the style..

Other mis-uses include building an implementation that is GETsful  (ie. does everything with http GET) or doing plain RPC where the URI is the command, doing CRUD with HTTP verbs etc. etc.

The point is that REST seems simple but it isn’t – it requires a shift in thinking (e.g. identifying resources, externalizing the state transitions etc.). However, as noted above, done right it can be an important and useful tool in your toolset

Published at DZone with permission of Arnon Rotem-gal-oz, author and DZone MVB. (source)

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


Jim Lombardo replied on Thu, 2009/05/14 - 8:56am

Although this post addresses important and interesting issues, the grammar is so poor that it is literally painful to read. I've noticed this about many blogs in the dzone and elsewhere. Is it that people don't care about the quality of their writing, or that English is just a 2nd language? :(

Arnon Rotem-gal-oz replied on Thu, 2009/05/14 - 10:00am

I don't know about others - in my case it is a combination of English as a second language and writing at the middle on the night (which is the only free time I have)

I am sorry if that's a problem but I do have a day job, family etc. 


Bill Bryson replied on Fri, 2009/05/15 - 5:08am

I found it perfectly understandable, and I never once felt any pain.

Thanks Arnon, although I really must learn REST properly at some point.

Dimitris Andreou replied on Fri, 2009/05/15 - 6:36am

doing CRUD with HTTP verbs etc. etc.
What is the problem with that?? It certainly is fit-ful :) with the metaphor of web resources that you PUT them, GET them, DELETE them, etc...

Arnon Rotem-gal-oz replied on Fri, 2009/05/15 - 3:06pm in response to: Bill Bryson


REST is an important architectural style so putting the time to learn it is worthwhile


Arnon Rotem-gal-oz replied on Fri, 2009/05/15 - 3:17pm in response to: Dimitris Andreou

For one it doesn't map exactly to CRUD

PUT is used to update a resource- but also to create a new one where the URI is set by the client

POST can be used to create a Child resource, a resource where the URI is determined by the server also with PUT you are expected to send a complete replacement where with POST you can update a part of the resource etc.

Additionally if you are using HTTP verbs as CRUD it is tempting to treat resources as tables - Personally I think that the database as a service is a bad idea


Artie Pesh-Imam replied on Mon, 2009/05/18 - 7:48pm

I'm not sure how you can call zealotry a problem with the technology itself.  It has nothing to do with the technology but with the way that people are using it.  If there's a problem you identified it's that REST is prone to misuse due to certain architectural decisions.

Additionally, I think that looking down upon zealotry or excitement about something belies humanity.  When something new comes along we explore it and we make mistakes.  Slowly though, we evolve our ideas and make general positive movement.  That's how we progress. If there were no zealotry or passion about technology, I fear we'd stagnate.


George Jiang replied on Tue, 2009/05/19 - 2:37am

Other mis-uses include building an implementation that is GETsful (ie. does everything with http GET) or doing plain RPC where the URI is the command, doing CRUD with HTTP verbs etc. etc.

What's wrong with doing CRUD with HTTP verbs?

George Jiang replied on Tue, 2009/05/19 - 2:42am in response to: George Jiang

Sorry, the question had already been asked and replied to. The CRUD view is actually widespread, I reckon.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.