The Web is made up of many resources and a resource can be any item of interest, for example, an online book store may define book as a resource and clients may access that resource with this URL : http://www.myEbookStore.com/Books.
As a result of accessing the above URL is that the representation of the resource is returned (e.g., books.html) which results in a state change of the client. Now the end users browser is displaying more than just the home page of the online book store, a more informative and detailed state than the previous.
Thus, the client application transfers state with each resource representation. Isn't this same as browsing a website over the INTERNET ???
WWW is like a REST system and many of such services are being used in our day to day activities like purchasing something from Amazon.com, using Facebook, and even using GMail. So you are using REST, and you didn't even know it.
REST stands for Representational State Transfer. REST is not a standard but an architecture. However REST does make use of certain standards like http, URL, XML , html etc.
Consider the case of myEbookStore.com which enables its customers to :
1. get list of books
2. get detailed information about a book
3. purchase books on-line
Get List of Books :
-----------------------
http://www.myEbooksStore.com/books
Note that "how" the web service generates the books list is completely transparent to the client. All that the client knows is, if he/she submits the above URL then a document containing the list of books is returned which is obviously displayed in the browser. Since the implementation is transparent to clients, myEbooksStore.com owner is free to modify the underlying implementation of this resource without impacting clients.So we can consider REST as a loosely coupled architecture.
Here's the document that the client receives:
<?xml version="1.0"?>
<p:Books xmlns:p="http://www.myEbooksStore.com"
xmlns:xlink="http://www.w3.org/1999/xlink">
<Book id="0120" xlink:href="http://www.myEbooksStore.com/books/0120"/>
<Book id="0121" xlink:href="http://www.myEbooksStore.com/books/0121"/>
<Book id="0122" xlink:href="http://www.myEbooksStore.com/books/0122"/>
<Book id="0123" xlink:href="http://www.myEbooksStore.com/books/0123"/>
</p:Book>
Note that the books list has links to get detailed information about each book. This is a key feature of REST. The client transfers from one state to the next by examining and choosing from among the alternative URLs in the response document. This is something like zooming the view on Google Maps. If you want to see the map of a location in Pune, the satellite will first zoom onto India, then Maharashtra and then Pune. At first level we get a list of countries from which we select India , then list of states in India from which Maharashtra is selected and then finally we get a list of districts in Maharashtra from which Pune is selected. We can see how data is refined gradually by taking decisions at each level. Lets get back to our BookStore example.
Get Detailed Information about a Book
-----------------------------------------------------
The web service makes available a URL to each book resource.For example, here's how a client requests book 0122:
http://www.myEbooksStore.com/books/0122
Here's the document that the client receives:
<?xml version="1.0"?>
<p:Book xmlns:p="http://www.myEbooksStore.com"
xmlns:xlink="http://www.w3.org/1999/xlink">
<Book-ID>0122</Book-ID>
<Name>JSON explored</Name>
<Description>This book explains JSON</Description>
<Versions xlink:href="http://www.myEbooksStore.com/books/0122/versions"/>
<UnitCost currency="USD">9.20</UnitCost>
<Quantity>10</Quantity>
</p:Book>
Again observe how this data is linked to still more detailed data - the versions for this book may be found by traversing the versions hyperlink. Each response document allows the client to drill down to get more detailed information. Thats the whole idea of REST, Representational State Transfer.
In-short lets summarize some important points related to REST/Web Services :
1. Client-Server model, where the client pulls representations.
2. Stateless, meaning state of the data provider is not important. So each request from client to server should contain all the information necessary to understand the request. For example searching google.com for the word "computer" is sent to google server as http://www.google.com/#hl=en&output=search&q=computer ... so the required information is sent from client to server irrespective of the state of the server... that's true because before searching, we never worry about the state of google's server.
3. Common interface. For example : All google search queries are accessed with a generic interface (e.g., HTTP GET, POST, PUT, DELETE) and there is no static page for all searches. Imagine having a static page like : http://www.google.com/computer.html for search results of "computer" keyword... a bad idea.
4. Interconnected representations - the representations of any resource are interconnected using URLs, thereby enabling a client to progress from one state to another.
5. Cache to improve network efficiency. Hence once a website is loaded all the external javascripts needed by the site will be cached.
6. Categorizing the resources according to the requirement of a particular resource. Clients can just receive a representation of the resource, or even modify the resource. For the former, make those resources accessible using an HTTP GET. For the later, make those resources accessible using HTTP POST, PUT, and/or DELETE.
7. Underlying implementation of REST needs to be independent of the URL or type of REST service (GET, PUT, POST, DELETE). This means a website can be built using either JSP or ASP, without impacting the service being provided to the client. Also data can be represented in JSON format or as XML format or any other structured format.
Note : APIs built using REST or conforming to REST design/architecture are said to be RESTful.
As a result of accessing the above URL is that the representation of the resource is returned (e.g., books.html) which results in a state change of the client. Now the end users browser is displaying more than just the home page of the online book store, a more informative and detailed state than the previous.
Thus, the client application transfers state with each resource representation. Isn't this same as browsing a website over the INTERNET ???
WWW is like a REST system and many of such services are being used in our day to day activities like purchasing something from Amazon.com, using Facebook, and even using GMail. So you are using REST, and you didn't even know it.
REST stands for Representational State Transfer. REST is not a standard but an architecture. However REST does make use of certain standards like http, URL, XML , html etc.
Consider the case of myEbookStore.com which enables its customers to :
1. get list of books
2. get detailed information about a book
3. purchase books on-line
Get List of Books :
-----------------------
http://www.myEbooksStore.com/books
Note that "how" the web service generates the books list is completely transparent to the client. All that the client knows is, if he/she submits the above URL then a document containing the list of books is returned which is obviously displayed in the browser. Since the implementation is transparent to clients, myEbooksStore.com owner is free to modify the underlying implementation of this resource without impacting clients.So we can consider REST as a loosely coupled architecture.
Here's the document that the client receives:
<?xml version="1.0"?>
<p:Books xmlns:p="http://www.myEbooksStore.com"
xmlns:xlink="http://www.w3.org/1999/xlink">
<Book id="0120" xlink:href="http://www.myEbooksStore.com/books/0120"/>
<Book id="0121" xlink:href="http://www.myEbooksStore.com/books/0121"/>
<Book id="0122" xlink:href="http://www.myEbooksStore.com/books/0122"/>
<Book id="0123" xlink:href="http://www.myEbooksStore.com/books/0123"/>
</p:Book>
Note that the books list has links to get detailed information about each book. This is a key feature of REST. The client transfers from one state to the next by examining and choosing from among the alternative URLs in the response document. This is something like zooming the view on Google Maps. If you want to see the map of a location in Pune, the satellite will first zoom onto India, then Maharashtra and then Pune. At first level we get a list of countries from which we select India , then list of states in India from which Maharashtra is selected and then finally we get a list of districts in Maharashtra from which Pune is selected. We can see how data is refined gradually by taking decisions at each level. Lets get back to our BookStore example.
Get Detailed Information about a Book
-----------------------------------------------------
The web service makes available a URL to each book resource.For example, here's how a client requests book 0122:
http://www.myEbooksStore.com/books/0122
Here's the document that the client receives:
<?xml version="1.0"?>
<p:Book xmlns:p="http://www.myEbooksStore.com"
xmlns:xlink="http://www.w3.org/1999/xlink">
<Book-ID>0122</Book-ID>
<Name>JSON explored</Name>
<Description>This book explains JSON</Description>
<Versions xlink:href="http://www.myEbooksStore.com/books/0122/versions"/>
<UnitCost currency="USD">9.20</UnitCost>
<Quantity>10</Quantity>
</p:Book>
Again observe how this data is linked to still more detailed data - the versions for this book may be found by traversing the versions hyperlink. Each response document allows the client to drill down to get more detailed information. Thats the whole idea of REST, Representational State Transfer.
In-short lets summarize some important points related to REST/Web Services :
1. Client-Server model, where the client pulls representations.
2. Stateless, meaning state of the data provider is not important. So each request from client to server should contain all the information necessary to understand the request. For example searching google.com for the word "computer" is sent to google server as http://www.google.com/#hl=en&output=search&q=computer ... so the required information is sent from client to server irrespective of the state of the server... that's true because before searching, we never worry about the state of google's server.
3. Common interface. For example : All google search queries are accessed with a generic interface (e.g., HTTP GET, POST, PUT, DELETE) and there is no static page for all searches. Imagine having a static page like : http://www.google.com/computer.html for search results of "computer" keyword... a bad idea.
4. Interconnected representations - the representations of any resource are interconnected using URLs, thereby enabling a client to progress from one state to another.
5. Cache to improve network efficiency. Hence once a website is loaded all the external javascripts needed by the site will be cached.
6. Categorizing the resources according to the requirement of a particular resource. Clients can just receive a representation of the resource, or even modify the resource. For the former, make those resources accessible using an HTTP GET. For the later, make those resources accessible using HTTP POST, PUT, and/or DELETE.
7. Underlying implementation of REST needs to be independent of the URL or type of REST service (GET, PUT, POST, DELETE). This means a website can be built using either JSP or ASP, without impacting the service being provided to the client. Also data can be represented in JSON format or as XML format or any other structured format.
Note : APIs built using REST or conforming to REST design/architecture are said to be RESTful.
