By Michael Haines, Sr. vCloud Architect (Security)
REST stands for "Representational State Transfer", which just serves to make things less clear, I think! So, instead of trying to dissect what this means, let us consider a simple web based application, something you do everyday.
1. (client) User goes to the home page and clicks a button.
2. (client) The browser submits an HTTP request to the server.
3. (server) The server send back a responds with an HTML document
containing some links and forms for example.
4. (client) User fill's in a form and submits it.
5. (client) The browser submits another HTTP request to the server
6. (server) The server processes the request, and responds with another
page.
The above exchange will continue until you stop browsing. Except for a few exceptions, most web sites and web based applications follow the same logic.
Let's take a closer look, and see how this is related to REST.
Putting it all Together
The key concept here is of a stateless client-server architecture where clients send requests to servers which in return send back responses. Pretty simple, eh? Rather than the client and the server maintaining state, the state is transferred in the requests and responses. This is what "representational" means, in that there is some representation of the state exchanged between client and server. There are a number of things that REST architectures impose. If you adhere to these constraints, your architecture is considered RESTful (we will discuss this a little later). It just means that your architecture obeys the REST constraints.
REST is not new, but it has become in-vogue fairly recently. Basically the entire web is built on REST concepts. Every time you click a button on a web page in a web browser (client) you're sending a request to a web server, which in turn sends back a response. This does not mean that all web services are REST-based, of course, just that they share some of the characteristics. A good example of a RESTful application is Google Mail. When you log into Google Mail, it sends a request to get the contents of your inbox (actually the latest n messages). The Google Mail server sends back a *representation* (the R in REST) of your inbox, which the client displays. You can then click on a message to read it, which sends a request to the server for the contents of the message. Actually, it's a little more complicated than this, since Google Mail can be doing things behind the scenes while you are reading messages. The point is that the Google Mail server has no idea which set of messages you are reading or which message is currently displayed. It keeps no state (i.e., it's "stateless".)
If it helps, you can consider the client being "at rest" when it's not actively engaged in communication with the server.
Also note that RESTful architectures do not have to be based on the HTTP protocol. You could implement them over any protocol you like. It's just that typically, HTTP is what RESTful implementations are based on.
Note carefully the list of 6 Constraints.
Summary
In this short background, we have attempted to provide an introduction into the concepts behind REST. A RESTful HTTP approach to exposing functionality is different from RPC, Distributed Objects, and Web services, it takes some mind shift to really understand this difference. Being aware about REST principles is beneficial whether you are building applications that expose a Web UI only or want to turn your application API into a good Web citizen.
