Friday, March 13, 2009

An introduction to REST Webservice


Hi, I assume that now you are just in a relaxed mood. After working hard for the entire day without taking any rest you may be reading this post. If I explain you now about SOA and Webservices, definitely you will require SOAP because you might be sweating!!. This might be true for atleast the Java guys.

So, I would like to take you to the same destination but without allowing you to use SOAP because you would be taking REST. So, in a RESTful way you can learn and create web services.

Ohh! You are smart! You got that what I wanted to convey. Yes. I was saying about creating webservices without using SOAP. This kind of webservices is called REST webservices or RESTful web services.

Are you interested and wondering how we can create webservice without using SOAP? Please follow me

What is REST?

If you had thought REST means rest, then you are wrong. REST means REpresentational State Transfer. This term REST was coined by Roy T. Fielding in his Ph.D. dissertation to describe a design pattern for implementing networked systems. Now, you might ask, what is meant by Representational state transfer?

Fine. Let us recollect the basic concepts. What is state? It is client’s data. Now, let me ask the second question. What is meant by representation? It is presenting data to the user in a different way i.e., in the form of HTML, XML or image etc. So, whenever client request for some resource, server sends data (i.e., client’s requested data) in a different way i.e., server represents data to the client. Whenever server represents data to the client, it puts the client in some state. It means client’s state changes. So, the server actually transfers state to the client through representation. This is nothing but REpresentational State Transfer.

In a more technical way we can define REST as follows. In REST everything is a resource. Even an Object is a resource. The information in that resource is called state. When you execute the method of that resource (object), that would transfer the state (information) through representation (as HTML or XML or Text).

I hope that you understood now what REST is. But you might be hesitating why we need it. The only solution to this is... follow me.

Why do we need REST?

You might have developed some websites or web applications. Can you recollect what you need to become a master? Are they simple XHTML, XML, URI and some server side scripting languages? Fine. Can you recollect what you need to develop a webservice? (not to be a master!). Hhhmmmm. You are thinking of a big list like the following... right?

XHTML, XML, URI, SOAP, WSDL, UDDI, W3C Standards, OASIS Standards, WS-I Standards, WSS . . . 􏰃􏰃􏰃􏰃

For providing even a simple services like currency converter or just to provide read-only data we still need to be comfortable with the above big list.

Though we call it as a web service, it is not following the real web architecture. It violates Tim Berners Lee Web Design.

For establishing communications between systems, we started with RPC, CORBA, DECOM, RMI/EJB distributed computing environments. Because of the main problems like proprietary protocol, port and data format with these, we came up with standard protocol, port and data format.

Yes. You are correct. We used XML as the standard data format to send it over HTTP, as the standard protocol. We called it as XML web services.

But, instead of making it much simpler than the previous distributed computing environments it has been growing...growing and growing. We used SOAP to send xml in a formatted way and this SOAP requires more and more specifications. That is why we needed the above big list.

As you are getting tired of this big list, you may require REST. REST needs only XHTML, XML and URI. It doesn’t require SOAP and hence doesn’t require any big list of standards. It is simple and easy to implement.

Now, you might be wondering what this REST is all about - Is it a standard or an architecture or a tool? Don’t worry. The next topic will help you finding the answer for it.

More about REST

  • REST is not an architecture. It is an architectural style. 
  • REST is not a designing tool. It is a design pattern. 
  • REST is not a standard. It uses standards. 
  • REST does prescribe the use of standards
    • HTTP 
    • URL 
    • XML/HTML/GIF/JPEG/etc. (Resource Representations) 
    • text/xml, text/html, image/gif, image/jpeg, etc. (Resource Types, MIME Types)
If I am asking you to define webservice shortly, how will you do it?
           Web service = SOAP over HTTP?
Fine. In the same way can you define REST?
REST = XML over HTTP? or
REST = XML or any media type over HTTP?
Hhhmmm... You are partially correct. REST is not only sending representation over HTTP, but by following some design principles.

Please move on to next topic to get into all these design principles.

REST Design Principles

Components in a REST system must obey the following constraints:
  • Identify the conceptual entities (resources) that you wanted to expose as service 
  • Identify the resources through URIs. It should be nouns 
  • Resources should be manipulated through representations 
  • Reveal data gradually. Don’t reveal everything in a single response 
  • The messages should be self-descriptive 
  • Hypermedia should be the engine of application state 
  • Specify the format of response data using a schema 
  • Describe your services using either WADL or WSDL or HTML 
  • Interactions should be stateless 

Where and When scenario

REST design may be appropriate when
  • Completely stateless web services are needed 
  • A Caching infrastructure can be leveraged 
  • The requirement is for point-to-point integration This means both the consumer and provider have mutual understanding 
  • Limited bandwidth exists between service consumer and provider 
    • e.g. having mobile device as a consumer 
  • Needed infrastructure for scalability, performance, security, reliability and extensibility 
  • Passing information thro’ RSS feeds 
  • For accessing static or nearly static resources within a SOA
SOAP design may be appropriate when
  • More security with encryption is needed 
  • Reliable messaging and transaction support are needed 
  • Attachment support is needed 
    • use SOAP when you need to send binary data or large attachments
I think you are now in a mood to develop REST webservices. You may be looking for any API or frameworks to help you. In the following section I have given some of the popular frameworks/API. Please don’t forget to have a look at it.

Frameworks/API for building REST WS 

  • JAVA 
    • JAX-WS 2.0 
    • JSR 311 API for REST 
    • Restlet, a lightweight Open source project 
    • Jersey, an open source JAX-RI 
    • Axis 2.0 
    • sqlREST – to expose any RDBMS as REST style WS
  • Ruby on Rails 2.0 for Ruby 
  • Python 
    • Django 
    • Cherrypy 
  • Microsoft 
    • Astoria 
    • MindTouch Dream 
  • Project Zero for PHP and Groovy


Congrats. You have successfully reached the end of this post. I think you might have got tired. Wanted to take rest? Good decision. Even I suggest you to go for taking… REST!

Do you know - Series - 4: Boxing and Unboxing - Integer assignment and comparison

We know about boxing and unboxing in Java. It is about automatic conversion of primitive type value into its Wrapper Object equivalent type...