Representational State Transfer REST

It was a Sunday evening when I was like crazy, talking to some random girl on facebook. And I think I have irritated her so much that she told me that I need to take REST. I quickly understood what does she meant by that, as if it is the sign of God from heaven telling me it’s time to switch from SOAP to REST, so from that evening onwards, I started using REST architecture.

Representational State Transfer REST

Web is stateless. Every time you interact with any website on the internet, you are perceiving a kind of stateless continuum in which everything changes whenever you do some action. The Action that you do destroy the current state of the web resulting in sending some HTTP requests, thereby creating another state on the basis of received response and try to keep that state and wait for the next action to take place.
Let’s look it like this. When you open a website, your browser send some request to the server where the website is hosted. When it receives the response, it downloads the HTML, CSS, JavaScripts whatever and render them all to create a page that you can see. Now imagine you then click a button in the webpage. What it will do is, it destroys the current page (current state of website) and sends the server some request that a button has been clicked, the server on the basis of action performed, send some response. The browser on receiving response, download the HTML, CSS, JavaScripts etc. again, for the action you’ve performed. Thus creating a new state for the website.
When you do some action again, the same process will repeat.
REST architecture thus uses these states to perform operations.

REST emphasizes in using web’s core methods GET POST PUT and DELETE used over HTTP to perform any process. Like getting data, creating entries, editing and deleting. There are two ways you can use REST either with WCF thus creating a so called RESTful services or by using WEB APIs.

Why REST?

It might be a good question at this point to ask that why REST? What’s wrong with SOAP? Well no doubt SOAP is powerful and simple as per its full name Simple Object Access Protocol, but not so simple and powerful enough to make it’s reach to every client. Here are the glimpse:

1. SOAP does not uses basic WEB verbs (GET POST PUT DELETE etc.) thus making it a bit slow to use.
2. SOAP uses XML for enveloping message which in turn make it complex to understand.

SOAP is very good if you need a very complex and tedious information to send. It is based on the standard XML format, designed especially to transport and store structured data. SOAP may also refer to the format of the XML that the envelope uses. While with REST you can use XML, JSON etc. where JSON is the preferred format. You cannot use JSON with SOAP as it itself uses XML format to encapsulate.

Benefits of REST Architecture

So far we have seen what is REST and how it is different from other architectures. Now let’s have a look on what are the actual benefits that one gets while using REST.

1. Self describing: If you have used WCF service before, you know that a client can detect a service only when it downloads a WSDL file, which it will read and process to get the contract of the service, thereby getting the information about the functions and classes present in the service. Well not with REST. Client need not to download anything, it just have to use the url to call a service’s method.
   For instance, in order to call ‘GetData’ method in a RESTful service, the client just need to make the call to the method like this:
   http://localhost:8987/RESTfulService/GetData
   
   
2. Scalability: As REST uses basic web verbs to communicate, a client need not to be intelligent enough to parse the complex annotations like that it is required in SOAP. So the RESTful service can be used to communicate with any sort of client.

So there are the two basic benefits REST architecture offers. Although the post is simple, still if you are not clear, wait for the next post where we put REST on work and stretch it up to it’s potential. We will see how WEB-APIs works and the power of the basic WEB verbs we talked about.

Stay tuned.
Happy Reading!!!