REST and Soap

REST stands for Representational State Transfer. This is a protocol for exchanging data over a distributed environment. The main idea behind REST is that we should treat our distributed services as a resource and we should be able to use simple HTTP protocols to perform various operations on that resource.

When we talk about the Database as a resource we usually talk in terms of CRUD operations. i.e. Create, Retrieve, Update and Delete.

What is SOAP?

“Simple Object Access Protocol” – a lightweight XML-based messaging protocol used to encode the information in Web service request and response messages before sending them over a network. It is used to send XML from one server to another via HTTP. The best part about SOAP is that it is universal and secure. SOAP messages are independent of any operating system or protocol and may be transported using a variety of Internet protocols, including SMTP, MIME, and HTTP. In order to fully understand SOAP, you will need to know about markup languages, namespaces .

SOAP Versions:

In July 2001, the XML Protocol Working Group released a “working draft” of SOAP 1.2. Within the W3C, this document is officially a work in progress, meaning that the document is likely to be updated many times before it is finalized.

SOAP Version 1.1 is available online at

http://www.w3.org/TR/SOAP/

The working draft of SOAP Version 1.2 is available at

http://www.w3.org/TR/soap12/

A SOAP message is an XML document containing the following elements.

Envelope: ( Mandatory )
Defines the start and the end of the message.

Header: ( Optional )
Contains any optional attributes of the message used in processing the message, either at an intermediary point or at the ultimate end point.

Body: ( Mandatory )
Contains the XML data comprising the message being sent.

Fault: ( Optional )
An optional Fault element that provides information about errors that occurred while processing the message

SOAP Envelope Element:

The required SOAP Envelope element is the root element of a SOAP message. This element defines the XML document as a SOAP message.
Example
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
...
Message information goes here
...
</soap:Envelope>

The xmlns:soap Namespace

Notice the xmlns:soap namespace in the example above. It should always have the value of: “http://www.w3.org/2001/12/soap-envelope”.

The namespace defines the Envelope as a SOAP Envelope.

If a different namespace is used, the application generates an error and discards the message.
The encodingStyle Attribute

The encodingStyle attribute is used to define the data types used in the document. This attribute may appear on any SOAP element, and applies to the element’s contents and all child elements.

SOAP Header Element:

The optional SOAP Header element contains application-specific information (like authentication, payment, etc) about the SOAP message.

If the Header element is present, it must be the first child element of the Envelope element.

Note: All immediate child elements of the Header element must be namespace-qualified.
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Header>
<m:Trans xmlns:m="http://www.gopaldas.org/transaction/"
soap:mustUnderstand="1">555
</m:Trans>
</soap:Header>
...
...
</soap:Envelope>

The example above contains a header with a “Trans” element, a “mustUnderstand” attribute with a value of 1, and a value of 555.
The SOAP mustUnderstand attribute can be used to indicate whether a header entry is mandatory or optional for the recipient to process.

SOAP Body Element:

The required SOAP Body element contains the actual SOAP message intended for the ultimate endpoint of the message.

Immediate child elements of the SOAP Body element may be namespace-qualified.
Example
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body>
<m:GetPrice xmlns:m=”http://www.gopaldas.org/prices”>
<m:Item>Apples</m:Item>
</m:GetPrice>
</soap:Body>

</soap:Envelope>

SOAP Fault Element:

The optional SOAP Fault element is used to indicate error messages.

If a Fault element is present, it must appear as a child element of the Body element. A Fault element can only appear once in a SOAP message.

The SOAP Fault element has the following sub elements:

<faultcode> A code for identifying the fault
<faultstring> A human readable explanation of the fault
<faultactor> Information about who caused the fault to happen
<detail> Holds application specific error information related to the Body element

SOAP Example

In the example below, a GetStockPrice request is sent to a server. The request has a StockName parameter, and a Price parameter that will be returned in the response. The namespace for the function is defined in “http://www.gopaldas.org/stock”.

A SOAP request:

POST /InStock HTTP/1.1
Host: www.gopaldas.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m="http://www.gopaldas.org/stock">
<m:GetStockPrice>
<m:StockName>CISCO</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>

The SOAP response:

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m=”http://www.gopaldas.org/stock”>
<m:GetStockPriceResponse>
<m:Price>80.5</m:Price>
</m:GetStockPriceResponse>
</soap:Body>

</soap:Envelope>

Stateless and stateful

Stateless means the state of the service doesn’t persist between subsequent requests and response. Each request carries its own user credentials and is individually authenticated. But in stateful each request is known from any prior request. All stateful requests are session-oriented i.e. each request need to know and retain changes made in previous requests.

Banking application is an example of stateful application. Where user first login then make transaction and logs out. If after logout user will try to make the transaction, he will not be able to do so.

Yes, http protocol is essentially a stateless protocol but to make it stateful we make us of HTTP cookies. So, is SOAP by default. But it can be make stateful likewise, depends upon framework you are using.

HTTP is stateless but still we can maintain session in our java application by using different session tracking mechanism.

Yes, We can also maintain session in webservice whether it is REST or SOAP. It can be implemented by using any third party library or you can implement by our own.

Google Reader API / Facebook API / Twitter API are good examples of the RESTful service.

There is huge difference between REST and SOAP. Comparing SOAP and REST is not just right as they are different things.

Both approaches work, both have advantages and disadvantages to interfacing to web services, but it is up to the web developer to make the decision of which approach may be best for each particular case.

REST SOAP
REST has no WSDL interface definition SOAP has WSDL, which is an XML-based language for describing Web services and how to access them.
REST is over HTTP/HTTPS. SOAP can be over any transport protocols such HTTP, FTP, STMP, JMS etc.
REST permits many different data formats – XML, plain text, JSON, HTML etc where as SOAP only permits XML.
REST is much more lightweight and can be implemented using almost any tool, leading to lower bandwidth and shorter learning curve. Using SOAP is little bit complex, It takes more time to learn and develop.
REST is limited by HTTP itself which can’t provide two-phase commit across distributed transactional resources, But SOAP can.
REST services are easily cacheable. Caching situations: If the information needs to be cached.
REST is almost always going to be faster. SOAP Service is little bit slower.
No error handling Built-in error handling (faults)
No constraints on the payload Payload must comply with the SOAP schema

 

  1 comment for “REST and Soap

Leave a Reply