Introduction to REpresentational State Transfer (REST)
Bhaskar S
02/28/2009
Introduction
We have been hearing of the acronym REST
quite often these days. So,
what is REST ? REST
stands for REpresentational State Transfer
and
comprises of the following set of architectural principles for building
any service oriented web application:
Identification
Representation
Linkage
Manipulation
Lets expand on each of the above mentioned principles.
Identification
Every web application has one or more resources. Resources could be
state or functionality. For example, Stock quote, Customer address,
Product detail, etc represent resources. In a web application,
resources are represented using URLs. For example, the URL http://www.mystore.com/dvd/wall-e could identify
the information for the DVD of the movie Wall-E.
What this principle is hinting at is that every resource in a web
application needs to be identifiable using an unique URL. The URL would
then act as an interface for interacting with the resource which makes
it easy for any application to deal with in a standard way.
Representation
Having exposed resources as URLs, what happens when a user or
another application accesses any of the URLs ? Accessing any URL in a
web application typically returns some data. For a human accessing the
URL from a Web Browser, the data may be returned as HTML, while an
application accessing the same URL could see the data as XML. In order
to support the various data representations, a web application
typically looks at the HTTP header “Accept”
to see what types the
client is willing to accept and format the data accordingly. For
example, accessing the URL for getting the DVD information for the
movie Wall-E in a Web Browser could return the following HTML content:
Output.1
<html><body> <h2><pre> <p>Genre: Animation <p>Language: English <p>Format: Widescreen <p>Year: 2008 <p>Produced By: Disney <p>Price: $24.95 </pre></h2> </body></html>
While accessing the same URL for getting the DVD information for the
movie Wall-E from a Java application could return the following XML
content:
What this principle is hinting at is that a web application should
be flexible enough to support the various data representations like
HTML, XML, etc. This would make the web application consumable by any
type of target, be it a Web browser or another application.
Linkage
Lets consider our Online DVD URL http://www.mystore.com/dvd/wall-e.
This URL returns the basic DVD information for Wall-E. Now, consider
the URL http://www.mystore.com/dvd/wall-e/details
that returns a very detailed information for the DVD Wall-E. For
brevity, lets assume the details include the basic movie information
plus the cast information. We could combine all that information as one
large monolithic content and return it to the target that accessed the
URL. That means the target would have to process all the content
irrespective of what it desired to see. Instead, if we return the
content with the basic DVD information plus URLs to cast information,
the target could drill down further by following any of the included
URLs to get the necessary details if needed. We are not forcing the
target to process all the details. The following illustrates this
hypothetical content in XML with URL links:
What this principle is hinting at is that content from a web
application needs to be modular with links to related resource URLs.
This approach allows an application to navigate the related resources
very easily and seek the desired information.
Manipulation
Having resources in an application generally leads to the need for
manipulating them. Resource manipulation includes creating, querying,
updating or deleting the resources. So what interface could we use to
handle these operations. This is where the standard HTTP methods GET,
POST, PUT, and DELETE come into play. GET
is used to query information
about a resource. POST is used to create
information about a resource.
PUT is used to update the information of a
resource. And finally,
DELETE is used to delete the information
about a resource.
What this principle is hinting at is the use of standard HTTP
methods for performing various operations on the resources. This way
any application can interact with your application in a standard way.
With this we should have an understanding of what REST
is all about
from a theoretical perspective. Let us firm our understanding of REST
by trying out the DVD example in Java.
Hands-on with REST
To get started we need a REST framework
for Java. Restlet is one of
the earlier and popular REST framework for
Java. You can download the
latest distribution from http://www.restlet.org.
We will be using Restlet as a standalone Java application for our
demostration. To use Restlet in a standalone mode, we only need to
reference the following two jars:
org.restlet.jar
com.noelios.restlet.jar
Lets look at our simple DVD example that only supports the GET
operation. First, we need a way to persist information about the DVDs.
Rather than using a Database, for simplicity, we will use in-memory
persistence using the Java HashMap. The following code illustrates the
simple DVD Data Access Object:
The DVD Data Access Object has information for only one DVD of
Wall-E.
Next, we need to represent the DVD information as a web resource.
The following code illustrates the DVD information represented as a
Restlet Resource:
Restlet Resource is an abstraction for a resource and also manages
the data representations for the resource.
Next, we need a container that can handle the URL requests from
clients for DVD information. The following code illustrates the Restlet
Application that manages the DVD resource:
Restlet Application is a container that manages and handles requests
for URLs such as http://www.mystore.com/dvd/wall-e.
Finally, we need a way to expose the Restlet Application through
HTTP. The following code illustrates how to expose the DVD Application
using HTTP connector in Restlet:
Executing the above code will start a HTTP server that is listening
on port 9090 for requests. Assuming the code has been setup as a
project in Eclipse, go ahead and Run the DvdRestService as a Java
Application. The following diagram shows the screenshot:
Figure.1
Now, try the URL http://localhost:9090/dvd/wall-e
from a Web Browser and you should see the following content:
Now, try a different URL like http://localhost:9090/dvd/nemo
from the Web Browser and you will see the following:
Output.4
The server has not found anything matching the request URI
Now that we are comfortable with Restlet, lets enhance the simple
example to support all the REST operations
such as GET, POST,
PUT and DELETE. We
will be using the Web Browser for GET and
the standalone Java clients for performing POST,
PUT, and DELETE.
The following code illustrates the simple DVD Data Access Object:
The following code illustrates the DVD information represented as a
Restlet Resource:
There is no change to either the DvdApplication or the
DvdRestService Java code.
The following code illustrates the test client that sends a POST request to create the Nemo DVD information:
The following code illustrates the test client that sends a PUT request to update the Nemo DVD information:
The following code illustrates the test client that sends a DELETE request to remove the Nemo DVD information:
To see the simple DVD application in action, start the
DVDRestService as before.
Now, try the URL http://localhost:9090/dvd/nemo
from the Web Browser and you will see the following:
Output.5
The server has not found anything matching the request URI
Execute the DvdCreateClient. Now, retry the URL http://localhost:9090/dvd/nemo
from the Web Browser and you will see the following: