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 .
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
The working draft of SOAP Version 1.2 is available at
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.
Message information goes here
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.
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.
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
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
Content-Type: application/soap+xml; charset=utf-8
The SOAP response:
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
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 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|