REST versus SOAP - the SOAP story

William Brogden digs into where the standards muscle of SOAP and its associated toolkits can trump the simpler style of REST.

The title "REST versus SOAP" is somewhat misleading. REST, which stands for Representational State Transfer, is...

a style rather than a standard. However, as discussed in my previous article, many software designers thinking about Web services have come to the conclusion that SOAP is overly complicated and services such as eBay and Google are exposing their massive amounts of data with REST style services.

Comparing REST and SOAP "styles"

REST relies on a simple set of "verbs" and puts all complexity into "nouns" that specify the resource. SOAP on the other hand permits quite a complex set of XML formatted commands and data transmission options.

The first major use of XML formatted messages in the forerunners of Web services used the XML-RPC protocol where RPC stands for remote procedure call. In XML-RPC, the client sends a message specifying by name the procedure for the service to run and the input parameters. In contrast, a REST style request does not care what procedure is run, it just asks for a named resource.

XML-RPC uses only a limited number of data types and a few simple data structures. It was felt that this protocol was not sufficiently powerful so work on SOAP, originally to stand for Simple Object Access Protocol. Since everybody realizes that SOAP is not simple and doesn't require object-oriented languages, we just call it SOAP.

Instead of XML-RPC's simple set of data types, SOAP was able to make use of the development of XML Schema for defining data types. SOAP also makes use of XML namespaces which XML-RPC does not need. The end result is that a SOAP message now starts with all sorts of XML namespace declarations adding more complexity and incompatibility between systems.

Another important, but frequently unappreciated point is that, in contrast with REST which requires HTTP, SOAP messages can be moved by any transport method which can handle Unicode text. Because of the convenience of HTTP for penetrating firewalls and the fact that developers are most familiar with the Web, HTTP transport continues to be emphasized.

As the computer industry has awakened to the commercial potential of XML-based Web services, there has been an explosion of ideas, opinions, arguments and standardization attempts by various organizations. The W3C has tried to organize efforts under the heading of "Web Services Activity," which includes the XML Protocol Working Group that actually deals with SOAP. The number of Web service related standardization efforts which are somehow related to or dependent on SOAP has multiplied to an astonishing degree.

The initial development of SOAP as an extension of XML-RPC emphasized the Remote Procedure Call aspect with method and variable names as derived from a WSDL document. These days one sees much more about using SOAP in the "Document" mode, which basically uses a SOAP envelope to move an XML formatted document. In any case, understanding the role of WSDL is essential to the use of SOAP.

Web Services Description Language or WSDL

The WSDL standard provides for creating an XML formatted document for describing a Web service in detail sufficient to permit creating client side code to access the service or server side code to provide it. The WSDL document for a service will give you:

* Address information for accessing the service

* The transport protocol (such as port numbers) for sending a message

* The names and interfaces use for all of the available functions

* The data types used in all requests and responses

Version 1.1 of WSDL was published by the W3C in March 2001 as a note for discussion, not an endorsed specification. Version 2.0 of the specification has been under development by the W3C Web Services Description Working Group and appears to be close to a final form. Although WSDL is most commonly used to specify SOAP services, in theory it can be used to specify REST style GET or POST operations.

Development environments supporting automatic creation of client and server code based on WSDL descriptions of a service are now widespread for a variety of languages used for Web servers and Web service clients. A Google search for "SOAP IDE" gets well over a million hits. There are also tools which can look at the code for a Java or C# object and generate the matching WSDL and code. Automatically generated code may get you running quickly, but may be far from optimized.

Security and SOAP

If businesses are going to transmit valuable information using SOAP, security is a top concern. Computer industry leaders have cooperated on development of a standard known as WS-Security, issued through the OASIS organization. This standard provides enhancements to basic SOAP messaging to handle the following concerns:

* Message Confidentiality - Since there are many ways to intercept HTTP messages, it must be possible to encrypt all significant information in both requests and response. Fortunately, advances in encryption technology allow for both encrypting message contents and ensuring that messages have not been altered.

* Client and Service Identity - It must be possible to verify the identity of the source of a SOAP request.


Both the REST and SOAP styles for the delivery of Web services are well established in developer consciousness. SOAP has a much more elaborate complex of standardization efforts and open source toolkits. Furthermore many IDEs now provide for automatic generation of SOAP based interfaces for existing code. SOAP is also indicated if you need to publish your Web service with WSDL or you need security functions such as message signing and encryption. On the other hand, if you need to make some information public with a simplified interface and without using a lot of processor power, REST may be for you.


Survey article on XML-RPC in the early days of Web services

Good survey article on WSDL essentials

General umbrella organization at the W3C for Web services

SOAP standardization at the W3C by the XML Protocol Working Group

WS-Security standard 1.1 has been developed by an OASIS committee

Open source implementation of Web services security in Java

This was last published in November 2006

Dig Deeper on Representational State Transfer (REST)



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

The sentence "Another important, but frequently unappreciated point is that, in contrast with REST which requires HTTP, SOAP messages can be moved by any transport method which can handle Unicode text" is misleading. Strictly speaking, REST does not require HTTP. REST is just an architectural style which can be used over anotyer transfer protocol.
Of course, in practice, when an arhcitcture follows the REST constraints, HTTP is used. Just like any SOAP-based architecture, in practice, uses HTTP as its transport protocol.
"SOAP has a much more elaborate complex of standardization efforts and open source toolkits". Well, yes, of course, because SOAP is not a uniform interface : any application defines its own names and types. So there comes the problem of having different tools being able to interoperate. The management of SOAP envelopes means a lot of work, so tool builders have produced services that ease this task - but wouldn't it have been simpler to avoid the problem (by not defining envelopes) instead of trying to solve the problem ??
There would have been many more remarks to be made (REST and standardization, REST and "simplified interface", REST and "without using a lot of processor power", etc. etc.)...