Grab some REST with your SOAP


Become An Insider

Sign up now and get free access to hundreds of Insider articles, guides, reviews, interviews, blogs, and other premium content from the best tech brands on the Internet: CIO, CSO, Computerworld, InfoWorld, IT World and Network World Learn more.

It's not one protocol vs. another -- they're both needed in the enterprise. Here's why.

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.


REST calls can be used to carry XML payloads as well as those that are just textual. But in line with its lightweight approach, REST is often associated with JavaScript Object Notation (JSON), which is a lighter version of XML that is as friendly for human interpretation as it is for machines.

JSON, on an average basis, is less verbose than XML and can be easily parsed with JavaScript's 'eval' function. However, due to its vulnerability for malicious attacks, it has to be used with caution and in trusted relationships only.

To continue reading, please begin the free registration process or sign in to your Insider account by entering your email address:
How to configure Wi-Fi channels for top network performance
View Comments
You Might Like
Join the discussion
Be the first to comment on this article. Our Commenting Policies