A bit of rest always helps. We have to seize every opportunity to pause and reflect on where we've been before making new plans to move forward. In the topsy-turvy world of SOA (Service-Oriented Architecture), which has now become one of the foundations of enterprise architecture, a bit of introspection goes a long way toward building greater robustness into the business applications on top.
Although the term SOA was coined in 1994 by Gartner Group's Alexander Pasik, SOA and related technologies didn't become mainstream pieces of enterprise architecture until around 10 years later. Some would say SOA still hasn't reached its full potential in the enterprise.
But even before there was SOA there were Web services. And behind the ecosystem of Web services was a protocol called SOAP, which at one time used to be an acronym for Simple Object Access Protocol. (With the newest SOAP specification from the World Wide Web Consortium -- version 1.2, which came out in 2003 -- SOAP is now supposed to be called just SOAP; it is no longer an acronym.)
REST had its roots in Roy Fielding's doctoral dissertation, presented in 2000 at the University of California, Irvine. It is now an integral part of HTTP, and as such is controlled by the broader standards bodies, including the Internet Engineering Task Force (IETF) and World Wide Web Consortium (W3C). Besides gaining immediate adoption in the loosely coupled world of online shopping and social media, it is being seriously considered for certain applications that are a bit heavier and go to the edges of the enterprise.
Well, just what are those applications? And, what would be some reasonable ways in which REST can complement SOAP? These are the questions we will address in a while, but let us first understand how differently these two approaches work.
How different are they?
To begin with, REST is aligned with HTTP. If we drag it deeper inside the enterprise, it can't ride on transports like IBM's MQ and Java Message Service (JMS) to help support, for example, larger business process management initiatives. SOAP, on the other hand, works with several different transport protocols.
REST does have service descriptions but they are textual and are meant to work with human intervention; REST's interfaces have to be coded manually based on those descriptions. In contrast, SOAP uses WSDLs that are XML-based and are machine readable.
In ad-hoc business relationships, as opposed to pre-arranged and trusted ones, SOAP-based interfaces can be built dynamically without human intervention. With the introduction of Web Application Description Language (WADL), REST's services can also be made XML-compliant. In parallel, WSDL 2.0 supports REST services. So the only limitation on REST in this regard, at this point, is the degree of adoption of either WSDL 2.0 or WADL.