<<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.>> You can read this in full at: <http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci1231889,00.html?track=NL-110&ad=572308&ad=572288&asrc=EM_NLN_775625&uid=521899&asrc=EM_NLN_780816&uid=5532089> Gervas
