Web 2.0 Building Block 1 - REST: Who does not need that?
I promised myself to stay on top of latest technologies as they shape the web. I have spent last couple of months understanding how web 2.0 works and will bring to you what in my mind are the building blocks.
When we think of Web 2.0 the sites that immediately come to our minds are probably - Facebook, YouTube, Twitter and there are many more. The thing that makes them successful is the collaborative nature of these sites. They interoperate with the web so well that they become a part of it. Imagine, would YouTube have been so successful had it not had the ability to enable embedding videos from YouTube on to your blog, site, etc.? Would you think twitter would have shared so much success had it not been due to the app ecosystem like twhirl, summize, etc. What would be the fun of facebook without the Apps? All these sites make this possible through web services. There are many ways of writing a web service but if you want your service to be really a part of web, be a friend of web then you need to think REST.
REST or Representational State Transfer is an architectural style for writing software for distributed systems. I will not go into the history or too much details of what it is for this post. Wikipedia link would do a way better job with that.
Why do I think REST is a building block of Web 2.0?
REST, makes it possible to write a web friendly web service. By web friendly, I mean a service that gets the most out of web without breaking it any way. To give an analogy here, lets consider traffic. There are some traffic rules like lights, lanes, etc. As long as all of respect those we can reach our destination safer and faster. The only difference here is there won't be a cop to fine us if we break REST rules. We will still loose but in the way of interoperability, scalability or at the minimum we will end up having an inconsistent behavior.
REST is basically a Resource Oriented Architecture, which means everything that is important on the server needs to be represented as a resource which has a unique Id. Examples of resource could be this blog entry, sales numbers, users, relationships between objects, etc. Once you have a resource, the next part is how to represent it. For REST, you should be able to represent each resource with a URL (or URI). Examples could be http://www.vishalsood.com/node/34 (entry to blog post), http://www.abcxyz.com/relationships/ObjectA;ObjectB or http://abcxyz/users/vishalsood. If you notice all these URLs make it easy for you to understand what the URL intends to communicate. This is not a REST requirement but good to stick to as it would make your web service very intuitive. A URL always points to a single resource and a resource may have one or more URLs pointing to it.
Http Verbs and REST
Once we understand the concept of resources and URLs, the next thing that pops to our is mind is, what can we do with these resources? REST prescribes using only standard http verbs while dealing with resources. These are GET, PUT, POST, DELETE, HEAD, OPTIONS (also TRACE and CONNECT though they are rarely used). It is a paradigm shift if you are used to RPC style communication but once you get into it, it is fairly straight forward. The idea is that you query a resource using GET, update(or create) using PUT and delete using DELETE. POST is almost like PUT but the only difference is that in the case of PUT, a new resource is created at a fixed location while in POST you just pass the data on to the server and the server then processes it in the way it wants. HEAD is just like GET but only retrieves the header information and not the content. OPTIONS, primarily tells you what you can do with the resource (E.g., what verbs are supported).
GET or HEAD are safe operations, this means that even if you call these 5 times, you will still get the same data. As these are read-only you don't need to worry about changing anything on the server with repetitive call.
PUT and DELTE are idempotent, this means that repetitive calls would leave the same effect on the server. These are not safe as they do change the server information but repetitions don't change it multiple times. If you are a math geek, multiplying any number by zero is idempotent. If you multiple once or many times the result is still zero.
POST is neither safe, nor idempotent, so it should be used with care. For example, a server can chose to create multiple sub-resources on multiple POST requests.
Statelessness and Cacheable
Statelessness is also a basic REST principle. The idea is that server should not store any application state. This means that client should supply all the state information with each request. For example, twitter uses pagination if number of messages is large, if you are on page 1 and want to request page 2, the request to twitter service should look something like this: http://twitter.com/user_timelines.xml?page=2. If you see in this example client is telling it needs the page number 2. If this information was stored on the server, it would break the REST principle. This is one of the more difficult principles to implement.
Let us see what are the implications of breaking this principle. If we do store the application state on the server, then the next client request would have to go to the same server. If it was a server farm, this would impact scalability and load balancing.Also, as long as we don't save the state on the server, we are ensuring that the resource is cacheable. Cacheable is ensured once we stick to each URL maps to a single resource and we include all state information with each request.
We discussed earlier that each resource should be identifiable with a URL, in this section we will discuss what should your RESTful web service return when called or in other words how is the resource represented to the client making the call. REST says that a resource can be represented in multiple ways. I mean there could be multiple output formats. For example a service that returns contact information could either return a contact info in the form of an XML, JSON or even vcf. All these are valid representations and could satisfy different kinds of client.
How is the representation determined for each request? In the ideal world the client should actually tell the service what it needs. There are a multiple ways a client can suggest this:
- Using URL. For example client could say http://www.contactservice.com/contacts/vishalsood.xml. In this case the web service should return an XML
- Using Accept headers like Accept, Accept-Langauge, etc. A client could say Accept:text/XML in the Http header and in that case the service should return an XML
Links and Connectedness
Last and a very important principle of REST is that the response returned by the web service should be complete. When I say complete I mean, when a resource is requested it should contain further links to child resources, etc. Also, if there are any related links those should be contained in the response. The idea is that a response should be sufficient for the client to dig deeper or request any other related information by following the links in the response.
Here are some example:
- If a web service is hierarchical - A site www.abcxml.com has users and each user has some books assigned to them. In this case if you request www.abcxml.com/users. This should return you a response with all users on the site and the links to each one of them (e.g., www.abcxml.com/users/vishalsood). Now if you follow the user link it should send you a response that contains all the books assigned to 'vishalsood' and links to each book for example: www.abcxml.com/users/vishalsood/BookA)
- If a web service returns responses in multiple pages, then each response should contain link to other pages. Live search is a good example here and the image (at bottom of the page if you search for anything) shows how the links are finally presented to the user:
Lastly, I would strongly recommend you read "RESTful Web Services" from O'REILLY for more details. I have tried to introduce the topic in this post but it has a lot to it that cannot be discussed in a blog post. The book below is an excellent resource to understand and build RESTful web services.