REST Architecture – Simplified

Sunday, November 14th, 2010 - By Abhishek Rakshit

Recently, while working on some collaboration functionality for our suite I got a chance to work on a REST (Representational State Transfer) based web server. There are many great resources about REST out there but most of them are quite technical and it took a me a while to get it. So, in this post I am trying to explain in some simple terms what I have understood about REST.

There has been a lot of interest about REST lately. Most of it is because of its features like being simple to implement and maintain REST also allowing projects to be scalable by supporting multiple back end services. Not only those, features like caching support and no contract architecture make REST an easy and quick way to setup an efficient web service. REST has often been compared to SOAP  and even said to be better in some cases. In my view SOAP and REST both are great ways to interface with web services and both have their advantages and disadvantages and it is up to the developer to understand the need of his project.

REST is an architectural style to easily create, modify and delete resources. By definition, REST is a guideline to build an efficient framework for communication between two machines. In fact, the most common example of REST is the world wide web. There are a few major concepts which make REST unique from other web services such as unique url mapping, stateless architecture, limited action verbs and standard data exchange formats.

Unique URL-Resource Mapping

The basic fundamental of REST is that each and every resource is mapped to a unique URL, where a resource could be a web-page, file, image, video etc. The urls for each resource are not some randomly given path but should be based on some logical way to access information. The figure below is a simple example of a maps website with url’s forming a logical information access tree. Having these logical names makes it easy to cache query results improving overall performance.


REST is a stateless architecture, i.e. all the information required to process the request by the server is contained along with the request. This includes the url, headers, query parameters etc as no information of the previous request is maintained by the server. Being stateless may decrease network performance by repetition of data but thats the trade off for allowing us to balance the load across multiple servers which, if done correctly can negate any network performance issues. So for services where no operations needs to be continued REST can work really well.

Action Verbs

REST advises use of the four verbs GET, POST, PUT and DELETE for all its communication and resource handling. Many developers are suspicious of having only four verbs but I’ve found that for most applications these are more than enough. GET is used by the client to access the resources on the server. It is an idempotent request and as such makes no changes to the resource on the server. Once the client has the resource it can use POST/PUT to modify it or create a new resource. Keep in mind when choosing between these that PUT is idempotent and POST is not. So if you call the server multiple times with the same PUT request you will still have the same effect. But in case of POST the resource can be partially modified with separate requests. The following discussion can provide you more information about POST and PUT. DELETE as you might have figured is used to delete a resource but is not supported by most modern browser and hence is not used much.

Data Exchange Formats

Now that we know how the client and server interact the next key aspect is the format of the resource as it moves between them. XML and JSON (JavaScript Object Notation) are common structural forms to accomplish this. In our server we used JSON for its inherent javascript support allowing most browsers to process it easily. Apart from that, the XML format is verbose and takes time to parse and also creates an impedance mismatch when converting to and from a POJO.


Some concerns about the REST infrastructure lie in fact that it uses http authentication, which still has a lot of room for improvements. Regardless, being a lightweight, quick approach towards setting up a web service does make REST a great architecture to go with.

Another interesting post by Ryan Tomayko about How I Explained REST to My Wife does a great job in explaining REST in very simple terms.

Have you used REST? Please share your thoughts about it.



  1. Great article.Although I haven’t use REST architecture in production applications I believe It is a great technology which can be proven very useful in many situations.

    • I agree nikos.
      When contrasting with other technologies out there, REST becomes really attractive due to its simplicity and ease of setting up, especially in the areas of web development. This is also due to the fact that it shares its core principles with the existing web structure.

  2. Nicolas says:


    I think more and more people understands the basics of REST.

    Beside, i don’t understand the cache thing as for the typical application, business resources can be changed by anyone, and so the cache can’t be used for “business” resources. that may change at anytime. I call them business resources as typically static content (like images, css, js) already benefits from the cache.

    Just an exemple :

    You have some sort of item list the user might want to buy. You want the backend to always remember this list, so whenever the user log in your application it has it’s cart.

    Typically the user will add/remove items. You want to retrieve the actual list. That is if the user has updated the list at work before going home, he want to see his updated list at home. Not an old cached one. If some item price or availabity has changed, he also want to see it.

    Being restfull as i understand, each time a new request on the cart occurs, even for the same browser session, the server being stateless has to request the cart again and again and again. Same for article prices. I see increased latency (more access to backend) and srrver load.

    Then you discovers that the UI is just not showing the item list, but also a list of sugested buys, a list of promotions. And maybe the last viewed item. On the bottom, the user see the status of it’s last command. How can you retrieve all of this in one REST request with a good URL ? How do you make a good URL ?

    If you use rest and need to update several ressourses coherently (ACID anyone ?) how do you do it ?

    • Hi Nicolas

      I have started using REST recently and haven’t had a chance to look into the details of f utilizing caching effectively in our project. I agree with you that in some of these complex cases finding the right way to use REST is not obvious. I myself would really like to see a post on “Caching in REST – Simplified” :)

      Though from what I understand about caching, is being stateless helps in maintaining a cache and everytime someone changes the resource (which is not very often) you can invalidate the cache. So every time you want to see the cart you can use the cached version and when a resource is changed you will have to query and update the cache from the server.

      About creating the correct URL, REST makes it simple by advising that the url should be a logical path to the primary resources the user wants (In this case the cart). For example url for the shopping cart scenario you present could simply be “http://xyzonline/user/userId/cart”. In the REST implementation, this url is just an address mapped to a controller. What extra informtion should be returned to the client is totally up to you. The controller responsible will collect all thse resources and send it to the client. We use a JSON map in this type of scenario and the JSP page configures itself according to the information provided. All this is accomplished in just one GET call and thats why REST is simple.

      Moreover REST is just a suggested architectural style and what matters is how you implement the backend controller. In term of updating multiple resources you can always conform to ACID by making sure the controller has separate transactions for each resource.

  3. Mohamed El-Beltagy says:

    I remember reading the following somwhere:
    REST = R.E.S.T = Read.Edit.Store.Terminate
    REST is used over the regular HTTP protocol.
    So, mapping REST to the HTTP protocol is done as the following:
    Reading is done using the HTTP’s GET method.
    Editing is done using HTTP’s POST method.
    Storing is done using HTTP’s PUT method.
    Terminating is done using HTTP’s DELETE method.

  4. [...] REST Architecture – Simplified – “Recently, while working on some collaboration functionality for our suite I got a chance to work on a REST (Representational State Transfer) based web server. There are many great resources about REST out there but most of them are quite technical and it took a me a while to get it. So, in this post I am trying to explain in some simple terms what I have understood about REST.” (by Abhishek Rakshit) [...]

Leave a Reply