Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Posted by Boris Lublinsky on May 20, 2009
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:
...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
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.
...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:
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)
... 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:
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.
... 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.
Learning to be a Good Product Owner: Foundation Skills
Regaining control of the data centre
Visit SOA Appliance Comparison Site
*Video Usage Model Tutorials
*Comparison to IBM DataPower X150
*Performance Benchmarks/Webinars
*Replace DataPower Program
FREE 1:1 Swap & Migration Services
"REST seems simple but it isn’t - it requires a shift in thinking."
While this is very true to get the full benefits from the architecture... we've found that embracing REST lends itself very nicely to a natural evolutionary and incremental progression.
First things first, simply exposing your resources with the Web Architecture simply to get things done is a fairly trivial task and provides consumers a very low barrier to entry to reuse your work. Subsequently, a couple of months in, we quickly discovered the power of the URI and linked data. Having a standard pointer for every resource in your heterogeneous collection of systems allows you to begin creating a system of systems with ease. A standard pointer, by the way, that's supported out of the box by nearly every language, platform, and framework in use today.
Today, a year after writing our first RESTful services, we have begun making use of the more advanced properties of the Web Architecture. We are creating a vast interlinked web of resources. We are utilizing HATEOAS in our interface designs, which we believe will add flexibility as we evolution our interfaces. We have begun including RDFa in many of our representations, which will allow us to "ask questions" of the system we've been unable to in the past.
So yes... it is a bit of a paradigm shift for developers to truly reap the more significant benefits from the Web Architecture, but you can have great productivity gains along the way as you move to embrace it as your default means to expose resources and services.
From the text I understand doing crud over http verbs is discouraged. Can someone explain?
@Andrew
I never said REST isn't a good architecture style. I think it is more complicated than it seems at first.
if you just sprinkle http GET and PUT on your otherwise RPC you have REST you might still see easier integration (by sticking to an ubiquitous standard like HTTP). But if your resources aren't really resources, you don't use hypermedia ("HATEOAS"), stateless communication etc. you can still have a mess of a system
@ Arnon
Never meant to imply you were saying it isn't a solid architecture, just saying that we've experienced an evolutionary path developers can take allowing them to learn to gain advantage of the breath of the architecture along the way. But your right... there's no Magic here... just some nice standard, powerful patterns who's underpinnings are ubiquitously supported. Some assembly required. Your parents (i.e. Senior Software Engineers) put it together. You've still got to architect your software correctly.
@Andrew:
>> will add flexibility as we evolution our interfaces...
I don't understand I thought REST "interfaces" were uniform? Are you adding verbs?
I fail to see how the things listed under "bad" or "ugly" have anything to do with REST itself.
@Stefan +1
Also...
>>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
... In defense, (not to sound like a "hammer" head :)) I would argue that endpoints exposing Atom or RSS representations inherently lend itself to event driven architecture.
Well,
for me the worst and ugliest thing is misunderstanding what rest really is and say "REST everything" just because its fashionable. I have seen so many RPCs services, implemented as XML/JSON over HTTP and being cold REST, that I am starting to wonder
@ Jean-Jacques
No... not evolving the actually HTTP methods... evolving the resources returned... allow new functionality (in the form of new URI's with well known relationships) to be exposed.
@Jean
I believe he was referring to adding the richer web architecture concepts that are beyond the uniform HTTP REST interface. Things like using hypermedia as the engine of application state, allowing more dynamic discovery of actions on services. Or using RDFa to embed rich semantics in resources, allowing clients to interact by only understanding a vocabulary instead of a specific resource format.
I've also experienced the evolutionary nature of utilizing the web architecture. Brian Sletten has a great slide on the conceptual stack to getting to a semantic web and it started with addressibility (resources at URIs). Nothing better than getting iterative benefits.
"... programming languages are not resource oriented so the handling code that maps URIs to tends to get messy."
This is the part I struggle with most. All the magic annotation sauce of APIs like JAX-RS notwithstanding, at the end of the day, I've to do a mental map from the handful of verbs and the URIs to method signatures like transferFunds(from, to, amt). It calls for a constant juggling between between two very different mindsets unless I reduce all my methods to doSomething(bagOfBytes) which throws out the window all of the nice object-orientation things we've been told are sacrosanct. IMHO, there's something missing that has to connect programming in the large (REST verbs, URIs) to the programming in the small(programming language APIs)...
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
11 comments
Watch Thread Reply