Rest White Paper

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 interactions.  Generality of interfaces,  Independent deployment of components,  Intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.

OPTIONS

:

GET HEAD POST

: : :

PUT DELETE TRACE CONNECT

: : : :

Let the client determine the communication requirements of the server without initiating a retrieval. Retrieve whatever data that is identified by a request. Return GET information without the message body. Perform an action on the server that may create a resource using the Request-URI. Create a resource at the Request Delete the resource identified by the Request-URI Invoke an application-layer acknowledgement. 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).