Introduction to Rest Protocol

1. REST stands for REpresentational State Transfer. It is most popular architecture used in cloud based
servers and is preferred over SOAP (Standard Object Access Protocol).
To put it straight, a peculiar SOAP request consists of XML file like:
<?xml version="1.0"?>
<catalog>
<book id="bk101">
<author>Gambardella, Matthew</author>
<title>XML Developer's Guide</title>
<isbn>54379678</isbn>
<genre>Computer</genre>
<price>44.95</price>
<publish_date>2000-10-01</publish_date>
<description>An in-depth look at creating applications
with XML.</description>
</book>
</catlog>
and a peculiar REST URL will look like: http://books.com/GambardellaMatthew/54379678
This clarifies how easy it is to use REST. REST is HTTP based
The URL above can be suitably modified to suit your need.
REST request consists of two parts, Verb and Content. Verb tells us what to do on the contents.
This is just like a Cellphone box with instruction manual, cellphone is the content and manual is the
VERB.
Peculiar characteristics of REST explained in short:
Every resource on the server can be reached by a unique URI like the above:
http://books.com/GambardellaMatthew/54379678
The message has the verb embedded in it, and the resource is a mere storage. You can retrieve a small
portion of a database, depending on the parameters you pass and the format
You need not bother about where and how is the data is stored. You can get the same chunk or data
either in XML or JSON or CSV, either encoded in UTF-8 or some other
encoding.
REST web services are "Stateless". The server doesn't bother once it sends the response to the client.
While shopping on some online shopping site, you query for some particular item and you add it to
your cart. The "cart" is a thing that resides on your machine and not on the server. (This is the most
common way of storing cart. There are "Persistent shopping Carts" which store the cart on the server)
If you add some 25 items to your cart and then if you clear your cookies, cache etc, all your efforts go
waste and you have to satrt all over again. Statelessness makes things simple a all the requests in HTTP
request sequence don't create confusion. HTTP is itself stateless and REST can easily marry with
HTTP.
REST is language neutral. You can implement in C#, Java, Python or language of your choice.
REST is cacheable. What is a Cache? Cache is some place other than the server itself, where the
response from server is stored temporarily. It can be on the end client, or at some other intermittent
server. If you want to experience the effect of cache, do a thing. Open some dense web page. (Unlike
google.com, contents on which are very few). Notice the time it take to fully load the page. Now, close
the page and gain notice the time. Now clear the cache of your browser. If you are using Chrome:
http://www.technipages.com/google-chrome-clear-cache , similar things can be done on Firefox, Opera
or other browsers.
ketkaravinash@yahoo.com

2. Now again load the page. The page will take slightly longer than previous. This is because, now the
page is loaded from the server and not from the cache that is stored on your machine. If you are a
developer, you always have to disable the cache so that the changes you make in your PHP, Javascript
code or if you make changes in the images on your web page, they get reflected in the browser.
Brief description about Verb part of the REST request:
GET : GET request is fired for GETting something (Pardon the pun) . When you type the URL like
http://google.com in your browser address bar, you are in fact requesting, "Go, GET me the search
engine facility from the google server".
Google and other search engines like Bing, continously crowl the web and "GET" information about
what is stored on different web pages at different web sites. Website owners have control over what to
make available to which engines, or completely hide some or all resources (that is, pages, images,
documents etc).
GET verb makes changes at the client side, ie the browser. It doesn't make any change at the server.
Search engines naturally shouldn't be allowed to insert, modify or delete anything on any site they
crawl. If you open a website and hit the refresh button of your browser n number of times, it doesn't
make any difference at the server. If you search 100 different terms using google, you, by your own
will cannot make any change at the server. But server can volunteerly make changes in its state, like
storing serch terms with IP address, your browsing habits reported by the cookies etc.
POST: POST is a verb designed for "creating" something at the server. You are filling a registration
form with columns like Nmae, Surname, address, email etc, on the website. You fill all the columns
and hit the "Register" button. Your browser then makes "POST" request to the server. Now again, it is
upto the server to allow your POST request to make changes in its state.
Your IP address is also sent with the POST request. If your IP indicates that you are from particular
region and the server doesn't allow POST request from that region, it communicates it to the client. (or
is supposed to communicate so to the client in the words comprehencible to the client.)
GET and POST are most widely used verbs in the REST. Daily life anology for these is telephonic IVR
(Interactive Voice Response). You dial the number of some utility helpline,
say, your cellphone provider. You want to GET something from other end. IVR responds and asks you
to dial some number. While dialing the number, you are POSTing something. The IVR in response to
your answer, provides the information. Now again you are GETting the information. When you want to
change some of your account options, you POST the information. Again, after checking the
information for some preset conditions, the IVR may reject the request and ask you to provide in
information again, or it may accept the request and change the state of the database.
Another thing that makes this work is the RESPECT FOR PROTOCOL. I say "Rkdfkldu". Did you
understand? surely not because I speak Klnj language and you speak Jyuk language.
If we both speak English, we both express our planet as Earth. These are liguistic protocol. There also
are cultural protocol. Different gustures mean differntly across cultures. When you show your thumb,
you may be warmly greeted somewhere, and somewhere you may bet beaten. One should be especialy
careful while using circasm and make sure
the server has ability to know the protocol, and not interpret it as insult.
Other verbs used in REST are: PUT, UPDATE and DELETE.
ketkaravinash@yahoo.com

3. PUT: PUT is silimilar to POST. Both PUT and POST send data to the server. Difference lies in what
happens when the same contents are sent twice to the server. If you are already registered your email on
a particular server, the server refuses your request and doesn't create a new record while using PUT.
But if your email exists and your phone number changes, PUT updates the existing record and doesn't
create a new one. PUT is used for UPDATION an POST for creation.
DELETE, as the name implies, deletes data from the server. Ofcourse, client can request a DELETE
but cannot force it. Server can schedule the DELETE at some suitable time, say
time when there is less load on the server. DELETE can be denied if the resource is critical or a
particular client doesn't have delete previllege for that resource. Facebook keeps the data for some
period after account closure for legal reasons.
ketkaravinash@yahoo.com