Friday, March 4, 2011

What are ReST, SOAP, JSON?


    Last week I was having a discussion with a friend regarding his current project, frankly it was a wonderful conversation until he said the following statement to me – "We are NOT using Web Services, We are using ReST". That's when suddenly it all seemed so pointless, if ignorance is bliss then he must be grinning from teeth to teeth. This article I try to bust the myths and misconceptions about ReST and another (not so) popular technology JSON. If people have followed my articles they remember about how we have many layers in the web service stack. IMHO the most powerful layer of the entire stack is the XML Messaging Layer, which deals with the actual data being transferred between client-and-server. The most popular way of transferring data is undoubtedly SOAP, but ReST and JSON are replacements for SOAP in that layer. The remaining layers of the stack can and would be retained as it is. So let us try and understand the differences between them.


ReST – Representational State Transfer is an idea that was conceptualized by Roy Fielding in the year 2000. This deals with the passing of vanilla XML documents (without any SOAP Envelope, Head or Body) as the XML Message over the HTTP network protocol. So put simply if we take the SOAP Payload (or the contents of SOAP Body) and pass it directly over HTTP we get ReST. Is it really that simple? Yes.
If we were to really understand ReST as Fielding conceptualized it, then we need to visualize the service as a URI. For example if I am talking of an order service (maybe books or ticketing or purchase order) , then such a service would be available to me at the following url: http://exampleurl.com/ServiceProviderName/orderService, At this service/URL we could perform 4 different operations (CRUD operations) using the HTTP verbs.


OperationSQL VerbHTTP Verb
Create New OrdercreatePUT
Retrieve Existing OrderselectGET
Update Existing OrderupdatePOST
Delete/Cancel existing orderdeleteDELETE




Thus if we want to add a fifth operation then we actually need to create a new service (i.e. a new URL) and then define all 4 or fewer verbs with the operation. Also there is currently no standard way to describe the ReST service (i.e. no IDL/WSDL), so the contents of the request would have to be pre-determined between the client and the server (this is not entirely true since WSDL 2.0 now supports ReST). Another important feature of ReST is it is always stateless, we DO NOT maintain any session between 2 interactions. [Also it should be noted that there is no standard way of providing Security or Reliability in ReST unlike SOAP]. Given so many limitations is ReST actually useful or is it just a fad. Well actually there are a number of places/situations where ReST is useful:
  1. Where the service is not complicated, (i.e. no requirements of security and state)
  2. When high level of scalability/performance is needed. (ReST allows for caching to increase the scalability)
  3. Bandwidth is of importance and needs to be limited. (In SOAP we are passing a lot of extra data all the time, ReST allows for URI based identification of resources)
  4. ReST allows easy aggregation of services.
I think the most popular usage of ReST is in blogging. If any of you have tried to post to a blog site using Microsoft Word, or retrieve a blog using Word, you are using ReST.




JSON – JavaScript Object Notation involves passing data in formatted text (NOT XML) across HTTP protocol. The main advantage of using JSON is that it is directly understood by JavaScript so we do not need to further process the data. JSON is almost exclusively used by AJAX clients and allows for easy serialization/de-serialization of data. The bandwidth is also minimized and speed is increased. The most popular user of JSON is Google. Almost all Google operations (gmail, http chat client, google docs) exclusively use JSON. The popularity of JSON is still very limited and hence I will not discuss too much into it. If you want to know more about it please do a Google search on it and get the required data.
In my next article I try to create a simple web service implementation for ReST and then port it to SOAP.


Edited:


The following table shows briefly the differences between SOAP,REST and JSON


SOAPRESTJSON
Message FormatXML inside a SOAP envelopeXMLTEXT
Interface DefinitionWSDL 1.1 , WSDL 2.0WSDL 2.0None
TransportHTTP, FTP, MIME, SMTP, JMS, etcHTTPHTTP (AJAX)


3 comments:

  1. Great... I came to know many things by this article... what is ReSTless webservice?
    Is it all non ReST webservices are ReSTless web services? or something more?

    ReplyDelete
  2. Very good info..

    ReplyDelete