In his new post, Arnon Rotem-Gal-Oz gives his opinion on REST (a more detailed REST discussion from Arnon can be found here)
According to Arnon, the top three advantages of using REST are:
- Relative ease of integration:
...a good RESTful API is discoverable from the initial URI onward. This doesn’t suggest that a any application calling on your service will auto magically know what to do. It does mean however that the developer reading your API trying to integrate it has an easier life. Especially if since hypermedia provides you the roadmap of what to do next
- Use of ubiquitous standards - HTTP is the most common implementation of REST:
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.
Arnon also discusses some of the drawbacks of REST. In his view, the two main REST drawbacks are:
- "Lo-rest" (using just GET and POST) implementations, which are specific to REST over HTTP:
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)
- Limitations of today’s programming languages:
... programming languages are not resource oriented so the handling code that maps URIs to tends to get messy. On the other hand it is relatively hard to make the REST API hyper-text driven (Which is a constraint of REST)
Finally, Arnon points to the ugly cases of REST, which, for the most part, are driven by misuse of REST:
- Zealous followers (term used by Arnon - proves again that REST arguments are often religious)
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.
- Misunderstanding of REST:
... 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.
Arnon concludes his post by stating, that:
REST seems simple but it isn’t - it requires a shift in thinking (e.g. identifying resources, externalizing the state transitions etc.). ... done right it can be an important and useful tool in your toolset. [but] ... as with any architecture/technology - a bad implementation can negate all the benefits
There seems to be an endless SOA debate on WS* vs. REST. In reality neither one is the "answer to everything" (be wary of the "Hammer" syndrome)
... when you take a holistic view of a complete business you are bound to see places where different architectural principles are a good fit. Architecture styles (and architectural patterns) are tools you can use to solve the challenges. There are places where a hammer is a great fit, but it is also wise to make sure the toolset has more than just a hammer.
For example, most REST implementations do not support asynchronous invocations and events. As a result, event-driven architectural style is probably a bad fit for REST. Another example, the separation of business and infrastructure concerns provided by the SOAP envelope is left to the implementer in the case of REST. Consequently, the implementation requires a significant number of potentially changing infrastructure concerns which might be not a good fit for REST.
REST has gained additional popularity lately with advances in Web 2.0, specifically Mashups and AJAX . In this case, REST services are often accessed from Javascript and use JSON as a marshalling mechanism. Based on this, many of the REST proponents claim that REST is easier to consume compared to the slew of WS* standards. Well, this is true if you are implementing consumer "by hands". On another hand, tools generating service consumer from WSDL and available in many programming languages make this job trivial.
The list of examples of REST vs. [anything] is endless and heavily depends on the list’s author. In his post, Arnon presents a good straw man for picking the appropriate architecture for an implementation.