Web Services, taking their name from the term for the individual applications that offer a remotely accessible service to client applications to form network applications. The two Web Services architectures are SOAPand REST discuss the technical meanings of those terms shortly.
The SOAP architecture’s approach to the problem is to make it feasible, at least in theory, to generate protocols that are customized to each network application—a kind of mass customization. The key elements of that approach are a framework for protocol specification, software toolkits for automatically generating protocol implementations from the specifications, and modular partial specifications that can be reused across protocols.
The REST architecture’s approach to the problem is to regard individual Web Services as WorldWide Web resources—identified by URIs and accessed via HTTP. Essentially, the REST architecture is just the web architecture. The web architecture’s strengths include stability and a demonstrated scalability (in the network-size sense). It could be considered a weakness that HTTP is not well suited to the usual procedural or operation-oriented style of invoking a remote service. REST advocates argue, however, that rich services can nonetheless be exposed using a more data-oriented or documentpassing style to which HTTP is well-suited.
Custom Application Protocols (WSDL, SOAP)
The architecture informally referred to as SOAP is based on Web Services Description Language (WSDL)and SOAP.2 Both of these standards are issued by the World Wide Web Consortium (W3C). This is the architecture that people usually mean when they use the term Web Services.WSDL and SOAP are frameworks for specifying and implementing application protocols and transport protocols, respectively. They are generally used together, although WSDL can be used to specify an application protocol that uses a transport protocol not specified using SOAP, and a SOAP-based protocol can transport a non-WSDL application protocol. WSDL is used to specify application-specific details suchas what operations are supported, the formats of the application data to invoke or respond to those operations, and whether an operation involves a response. SOAP’s role is to make it easy to define a transport protocol with exactly the desired semantics regarding protocol features such as reliability and security.
Defining Application Protocols
WSDL has chosen a procedural operation model of application protocols. An abstract web service interface consists of a set of named operations, each representing a simple interaction between a client and the web service. An operation is analogous to a remotely callable procedure in an RPC system. An example from W3C’s WSDL Primer is a hotel reservation web service with two operations, CheckAvailability and MakeReservation.
Defining Transport Protocols
Although SOAP is often called a protocol, it is better thought of as the foundation of a family of protocols, or a framework for defining protocols. As the SOAP 1.2 specification explains,“SOAP provides a simple messaging framework whose core functionality is concerned with providing extensibility.” SOAP uses many of the same strategies as WSDL, including message formats defined using XML Schema, bindings to underlying protocols, MEPs, and reusable specification elements identified using XML namespaces.
SOAP Message Structure
A Generic Application Protocol (REST)
The WSDL/SOAP Web Services architecture is based on the assumption that the best way to integrate applications across networks is via protocols that are customized to each application. That architecture is designed to make it practical to specify and implement all those protocols. In contrast, the REST Web Services architecture is based on the assumption that the best way to integrate applications across networks is by applying the model underlying the World Wide Web architecture (Section 9.1.2). This model, articulated by Web architect Roy Fielding, is known as REpresentational State Transfer(REST).