The role of REpresentational State Transfer (REST)

architectural principles in Web Based Computing

Long before SOA became a buzzword and SOAP became a necessary part of our SOA
infrastructure, there was REST. And though SOAP and its other WS-* specs have stolen the
limelight from this alternative service-oriented architecture, REST is gaining a lot of traction as
Web 2.0 takes the Internet by storm.

REST (Representational State Transfer) which was detailed in Roy Thomas Fielding's doctorate
dissertation "Architectural Styles and the Design of Network-based Software Architectures" in
year 2000, which can dramatically reduce the investment necessary to provide service-oriented
access to enterprise resources. Fielding used the term to describe a technique and best practices
for retrieving data formatted in XML over HTTP for use in applications.

The Fundamentals

REST is an architectural style, not a standard or specification, built on existing, well-understood

standards governed by the W3C, such as HTTP, URI (Uniform Resource Identifier) and RDF
(Resource Description Format). REST services are focused on access to resources.

Let’s Enter the World of REST.

Resource: A resource is something identified by a URI, retrievable. On the Web, it’s not a
resource that is retrieved, but a representation of a resource.

Representation: A representation is usually a document, or a media object like an image or audio

file. The resource and the representation are not the same thing. Think of the resource as
something that exists outside of the Web. It could be a document, a physical object, or even a
concept like today’s weather. Many different digital representations could exist for a given
resource

State: The inter-object communication

of HTTP is client-server pattern of
transferring state to the caller. The
client maintains the state and ensures
each request from client to server
contains all the information necessary
to understand the request.

Transfer: The URI and HTTP offer a

uniform interface between client and
server through which representation
of resources may be transferred. Like
an object-oriented system, the transfers are carried out by means of method calls. HTTP offers
just eight methods. HTTP (and hence the Web) is built on a language of many nouns (URIs) but
very few verbs. The verbs are the HTTP methods. By far the most common methods in use are
GET and POST.
The combination of GET, POST, PUT, and DELETE offers all the basic interaction needed from
the client to retrieve, create, update, and delete data on the server (CRUD System).
Goals of REST
HTTP Methods: (RFC 2616)

 Scalability of component OPTIONS : Let the client determine the communication

interactions. requirements of the server without initiating a
 Generality of interfaces, retrieval.
 Independent deployment of GET : Retrieve whatever data that is identified by a request.
components, HEAD : Return GET information without the message body.
 Intermediary components POST : Perform an action on the server that may create a
resource using the Request-URI.
to reduce interaction
PUT : Create a resource at the Request
latency, enforce security,
DELETE : Delete the resource identified by the Request-URI
and encapsulate legacy TRACE : Invoke an application-layer acknowledgement.
systems. CONNECT : Reserved method for tunnel requests to a proxy.

REST achieves these goals by applying the following constraints:

 Resource is unit of identification.

 Resource is manipulated through exchange of representations.
 Resource-generic interaction semantics.
 Self-descriptive messaging.
 Hypermedia is engine of application state.

Advantages of REST

 It uses well documented, well established, well used technology and methodology.
 It's already here today; in fact it's been here for the last 12 years!
 Resource centric rather than method centric.
 Given a URI anyone already knows how to access it.
 It's not another protocol on top of another protocol on top of another protocol on top of...
 The response payload can be of any format (some may call this a disadvantage, however the
Web copes with it, it's just a case of defining the application grammar).
 Uses the inherent HTTP security model, certain methods to certain URIs can easily be
restricted by firewall configuration, unlike other XML over HTTP messaging formats.
 REST makes sense, use what we already have; it is the next logical extension of the web.

Role of REST in Web Based Computing

Give REST to WEB 2.0

The WEB 2.0 has gain tremendous attention in the recent years. However, ignoring REST in WEB
2.0 is like saying if it’s a liquid, it can be drunk by humans. Sure, humans can drink anything that
is a liquid, but the bigger question is, will you survive? Sometimes you will, and sometimes you
won’t!

As they say "A picture says a thousand words", The Role of REST in WEB 2.0 can be understood
from the image given below:
RESTifying SOA. (SOA everywhere, Heard of WOA !!!! )

Web-Oriented Architecture (WOA)

represents SOA plus the Web plus
Representational State Transfer, often
called REST. It’s a descriptive term for a
subset of SOA.

WOA is making people fall back to

simpler and more straightforward
methods that just work, and hide the
protocol complexity in the application
state. As far as REST and WOA are
concerned, you don’t need anything
more complex than HTTP, one of the
most scalable, proven, and widespread
protocols on the planet, along with
HTTP’s verbs: GET, POST, PUT,
DELETE. Add some plain old XML to hold your data and state to top it all off.

WOA is the most interoperable, easiest to implement, and most highly scalable technique for
building great, open Web services that anyone can use. But it is definitely not the hammer for
every job. Certain applications, particularly in the high-end of the enterprise, just flat-out require
the more sophisticated portions of the SOA stack.
REST in Co-Evolution of SOA and Web 2.0

Service-oriented architecture initiatives tend

to have application integration as one of
their primary goals, while Web 2.0 software
often has communities, user participation,
and unintended uses as primary goals that
are enabled by extremely simple
consumption and integration. Both,
however, are accomplished by exposing
open, interoperable interfaces to the public
so that the number of consumption
scenarios increases and more value can be
accessed or distributed. In this way, Web
2.0 and SOA both have the fundamental
value of openness, with Web 2.0 having the
clear edge on encouraging the important
part: the potential of social computing.

However, there is also where the differences start. Interoperability is accomplished very
differently in Web 2.0 than it is in formal SOA. Web 2.0 adherents tend to let others integrate
with them using Web-Oriented Architectures (WOAs) based on REST, JSON, and
POX/HTTP more than the SOAP approach that enterprises often prefer. SOAP is the
underpinning standard of the majority of SOAs, and complex variants collectively known as
WS-* are on the way to increase SOAP's features for the enterprise by adding transactions,
policies, advanced security, routing, and much more.

Is hammer or screwdriver a better tool??

Well, that depends on the situation and the need. Similarly Web services work well with both the
styles of use (i.e REST and SOAP). In a highly competitive business environment, the risk of lost
time and investment means that making the best decision up front is vital to success.

Web services are about interoperability, and SOAP and REST deliver the goods. We can use
either SOAP or REST to build web services. But what is the best way to create a loosely-coupled
Service interface? That again depends on the enterprise. The business doesn’t care about the
resources or even the Services themselves, but rather the business value that result from
interacting with those resources and Services. It’s up to the architect to understand when to apply
different architectural and implementation styles to best address their organization’s ongoing
business challenges.

“Finally we conclude by stating that REST is here to bring out the better of two worlds namely
SOA and WEB 2.0”

Author: Siva Prasanna Kumar.P Blog: http://soa2world.blogspot.com/

Disclaimer: Author is not responsible for any unintended use of the above article or damages caused by using the technologies
mentioned in the article (if any).