This is a followup to my earlier post on the resource oriented enterprise, I had some good feedback much from the REST mailing list which I summarize here. As I said there this is an attempt to get some of these ideas documented as they largely seem to be invisible.
Only solutions that produce partial results when partially implemented can succeed. The network is littered with ideas that would have worked had everybody adopted them. Evolvable systems begin partially working right away and then grow, rather than needing to be perfected and frozen. Clay Shirky
I came across that quote from Clay Shirky as I was writing this which seemed very relevant.
Jan Algermissen added the two following very good points:
the use of REST brings the decentralization aspects of the Web into the enterprise world and allows designers and developers of networked systems to create and evolve their components without the resource and time consuming effort of bringing them into a single room to discuss APIs. In geographically distributed organizations this might sometimes even be impossible.
the use of REST facilitates fragmented change. It deliberately provides room for evolution (e.g. format extensions) that can bypass the main organizational control. Evolutions that turn out to be valuable can flow back into the main line while others silently die. No harm to ongoing communication between systems is done by either of those.
These are really very important points. You cannot really undersell the success of the web, and the web took off with its own architecture despite attempts to force other architectures on it. The decentralization and the ability to reuse and mashup services to make new things is part of that architecture. The idea of introducing REST to the enterprise is to help the enterprise leverage the agility of the web architecture, and to make building new enterprise applications cheaper and easier.
Benjamin Carlyle made the good point that you can view REST as an evolution of SOA, as better easier to consume services. This does not quite fit with my view of history, but I do agree that it is a good way to sell it now as “SOA on steroids” as he says. He linked to useful sounding book coming out later this year on SOA and REST. He examines seven SOA objectives from Thomas Erl’s book, Principles of Service Design:
Increased Intrinsic Interoperability
Made better with a uniform interface – Interoperability stops being an “easy to plug together at design time” thing to “easy to plug together at run-time”
Increased Federation
This is not an explicit target of REST, to get everyone using the same service. However, it is compatible with REST. It also occurs in practice on the Web through market forces.
While SOA emphasises reuse of services, REST emphasises reuse of components (including services), media types, and connectors.
Increased Vendor Diversity Options
More or less the same for SOA and REST, however REST is probably still less mature in the enterprise space. Time will change this.
Increased Business and Technology Alignment
ie, we build services that the business wants, and can change in pace with business objectives
Again REST doesn’t particularly target specific valuable services, but is compatible with the notion
REST is more capable of incremental upgrade than a classical SOA, especially “dynamic evolution”.
Increased ROI
Classically realised in SOA by reuse of services, which again is compatible with REST
Again, a uniform interface produces wins on this front when compared to classical SOA
Increased Organizational Agility
Classically realised by being able to build new applications quickly by reusing existing services
Again, compatible with REST and again a uniform interface produces improved performance
Reduced IT Burden
Few legacy systems doing more means less maintenance and related support activities – again compatible with REST.
REST makes maintenance easier with its focus on dynamic evolvability
Darrel Miller has obviously been through some maintenance pain. The web architecture was always designed to not have centralization, and that obviously mean that things are incrementally upgradeable.
For me the business case for REST is around client/server coupling and maintenance effort. My experiences with SOAP API’s on the Microsoft platform were that if you sneezed on the server API that defined the contract you had to recompile and redeploy the clients. And then there is versioning. In the WCF world versioning is a potential nightmare, with changing URLs, XML namespaces on service contracts, message contracts and data contracts.
I believe that REST’s use of hypermedia and conneg make maintenance, deployment and versioning much easier, which translates to lower costs to the business in the maintenance phase of an application.
Bill Burke responded to Darrel saying how he has been using it.
Also, I think interoperability is much easier to achieve with REST because the ubiquity of HTTP. This has a huge positive side-effect for integration as well. My gut tells me that SOA Governance could really reap the benefits of a RESTful architecture as well, but I don’t have any details yet on how.
All this plus Darrel’s comment on the fragility of SOAP stacks sold me on the idea of REST which is why I’ve been really pushing it hard at Red Hat and all our middleware projects.
A very useful set of responses, thanks to everyone. Will be writing more on this soon.