User:Xephyr826/SOAP and REST

=SOAP and REST= This article gives an overview of SOAP and REST. SOAP and REST are two approaches to creating web services. Both approaches create web services for machine-to-machine interactions over a network. Most web services are implemented as either SOAP APIs or REST APIs communicating with HTTP. It's important to note that SOAP is a protocol specification while REST is an architectural style.

SOAP Specification
Simple Object Access Protocol

The SOAP specification defines a protocol for using XML to exchange information. SOAP messages travel between SOAP nodes, from sender to receiver. The SOAP specification lets developers create very well-defined web services with predictable behavior. SOAP web services are also supported by many powerful developer and client tools.

SOAP Messages
Each SOAP message is an XML document with the following elements:


 * Envelope—identifies the message as a SOAP message. Contains the Header (optional), Body, and Fault (optional) elements.
 * Header—optional element used to add information not directly part of the message body, but useful to processing the message and extending capability.
 * Body—mandatory element carrying the message's main information.
 * Fault—optional element used to communicate errors in message processing.

Simple SOAP message:

Once a receiver processes a SOAP message, the receiver sends back its own SOAP message as a response. For a detailed example of SOAP messages and message processing, see the W3C SOAP Primer

In addition to defining SOAP message structure, the SOAP specification also describes the following:


 * Processing Model—defines how nodes process messages
 * Extensibility Model—describes how to add capabilities to the SOAP messaging framework
 * Protocol Binding Framework—defines how the messaging framework functions in a specific protocol like HTTP or SMTP

WSDL
Web Service Description Language

WSDL is an XML format often used to describe SOAP web services. WSDL is not part of the SOAP specification and has its own specification. WSDL can completely describe a web service as a series of service definitions of the data the each service accepts, the operations each service performs on the data, and the location of each service. Once a web service is described in a WSDL file, code generation tools can use the WSDL to generate documentation and clients to access the web service.

REST Architecture Style
Representational State Transfer

Developers use the REST architectural style to create fast, scalable, simple, and modifiable web services well-suited to working over HTTP.

The REST architectural style defines six constraints for architectures based on networks like the Internet:


 * Client-server—clear separation between client and server. Enables modifiable clients and servers which can evolve independently of each other.
 * Stateless—the server does not store any information related to the state of the client. The client's request contains all the information needed to understand and process the request. As a result, servers recover from failed requests quicker and use less storage.
 * Cacheable—data from the server to the client must be labeled as cacheable or non-cacheable. If the data is cacheable, the client may reuse the data for equivalent requests. This constraint reduces the number of requests and improves network traffic.
 * Uniform Interface—all clients, servers, and components within the network must communicate using a common interface. Information flows through the network in a standardized form and allows all components to evolve independently. See the section below for additional constraints on the uniform interface.
 * Layered System—additional layers can be added to the network with the constraint that components within one layer cannot require knowledge of other layers. Layers such as load balancing layers can be added to improve network performance without disrupting clients and servers.
 * Code on demand (optional)—in cases where it's beneficial, servers can push code and additional features to the client.

Uniform Interface
The uniform interface constraint is the central feature of REST architectures.

REST also defines the following constraints on the interface:


 * Resource Identification—all information in a REST architecture is accessed as a resource mapped to a resource identifier. The resource at a resource identifier can be empty or a set of resource representations and/or resource identifiers. Servers and clients may update the resource value. The resource author must create a resource identifier which adequately describes the resource value.
 * Manipulation of Resources Through Representations—when REST components interact with each other, they pass complete representations of the resources of data. Representations consist of data and metadata, all the information you need to define the resource and it's state and act on it. Metadata can include the client's preferred data type for the representation, for example, JSON or XML.
 * Self-descriptive Messages—to satisfy the stateless server constraint, messages must contain all the information needed to process the message.
 * Hypermedia as the Engine of Application State—to satisfy the client-server constraint, clients discover additional resources by using hypermedia from the resource indicators contained within the resource representation of a response from the server. Clients should not need prior knowledge of all of a web services resource identifiers to communicate. The Client should discover additional resources through resource identifiers sent from the server.

REST Web Services
Using the REST architecture style, you can implement a REST Web Service as a REST API using HTTP as the common interface. Because REST was created with the Internet in mind, many of the architecture constraints can be satisfied with common web technologies like HTTP. REST does not specify a required representation format and can support multiple format types. For example, REST web services commonly support JSON or XML as message formats.

Simple REST Example:

GET http://example.com/student/567

Response in JSON:

For a detailed description of the REST architectural style, see http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm.

REST Popularity
Over time, REST web services became more popular than SOAP web services and new web services commonly use the REST architecture style. SOAP, while supported by powerful tools and WSDL, adds considerable overhead to each message and to the implementation code. Developers tend to choose REST for it's HTTP design and flexible, simple message format.