This is an exploration of REST, as pulled out from various sources on the Web.

1. RE presentational S tate T ransfer

2. Think of REST this way – when a browser gets and displays the elements which make up an HTML page, it is getting a representation of the current state of that resource .

3. What is wrong with XML/RPC and SOAP ? Roy Fielding feels that using HTTP to piggyback application protocols through firewalls the way XML-RPC and SOAP do is a fundamentally misguided idea. It defeats the idea of having a firewall and results in firewall vendors having to detect the piggybacked protocol in order to protect the system. Since most SOAP applications use HTTP for exactly that purpose, you can see where the conflict between REST and SOAP got started. Fielding feels that if you are going to use HTTP, it should be with HTTP semantics.

4. Resources and Representations The last important bit is the distinction between a resource and its representations. A resource is the real thing that is being acted upon with a request. For example, deleting a file from a folder, adding an entry to a blog, or reading the heart rate of a patient. The data transmitted to and from the resource is a representation of it. Sometimes the representation can be faithful, such as in a file copy, and sometimes it's just a description, such as the sound of someone's voice. The end effect is that we never send or receive resources, only their representation. The format of the representation is determined by the content-type. And the interaction of the representation on the resource is determined by the verb.

5. REST Verbs Let’s explore the four basic verbs (GET, PUT, DELETE, POST) to define application behavior

6. GET The GET verb is used to read a resource . An important rule of thumb is that a GET operation is safe . That is, it can be done repeatedly without changing visibly the state of the resource. This property is very important for various reasons. First, indexing engines use GET to index the contents of a resource. So it would be bad if indexing a resource also changed it. Second, intermediaries, such as proxies, may cache results of a GET operation to accelerate subsequent accesses to the same resource. Let's assume we have an image as a resource at "http://myserver/myphotos/mywedding.img". We can retrieve this image by doing a GET operation on it: GET http://myserver/myphotos/mywedding.img Similarly, we can also query a complex resource, such as a blog, to get parts of the data: GET http://myserver/myblog/2006-12-25T11:12:05.001Z/comments?query=author:anonymous The GET verb is the fundamental read operation for resources. All data resources support GET, but not all behavioral resources do. While a GET request cannot have side-effects, it can return only parts of the resource. This means that GET can act as both a read operation and a query operation .

7. PUT and DELETE The PUT and DELETE verbs allow a request to alter the state of a resource atomically . For example, if we wanted to change the image of our earlier example, we could upload a new one using the same URI and the PUT verb: PUT http://myserver/myphotos/mywedding.img This operation would indicate to the server that we want to replace the target resource with the contents of our request. Similarly, if we wanted to delete the image, we could use the DELETE verb: DELETE http://myserver/myphotos/mywedding.img This operation states we want the server to delete or reset the target resource. Note that PUT and DELETE apply to the entire resource and not just parts of it. So, when doing a PUT operation, the entire resource is replaced . PUT acts on the entire resource! The same is true for DELETE: DELETE acts on the entire resource! The PUT and DELETE operations are atomic . If two PUT operations occur simultaneously, one of them will win and determine the final state of the resource. The same is true when a PUT and DELETE operation occur simultaneously. Either the resource's final state is updated or it is deleted, but nothing in between. In the case of two simultaneous DELETE operations, the order does not matter, because deleting a resource again has no effect.

8. POST The POST verb can carry a variety of meanings. It's the Swiss Army Knife of HTTP verbs. For some resources, it may be used to alter the internal state. For others, it's behavior may be that of a remote procedure call ( http://en.wikipedia.org/wiki/Remote_procedure_call ). In the example of our blog, we could add a new blog by using the POST verb: POST http://myserver/myblog The POST operation is very generic and no specific meaning can be attached to it. In general, use POST when only a subset of a resource needs to be modified and it cannot be accessed as its own resource; or when the equivalent of a method call must be exposed.

9. First of all a web service needs a communication channel . You need to be able to ask something to the service and the web service then needs to respond. In the REST web service you ask something just by typing a url. In the url you give certain parameters that define which information you want the web service to return to you (just like giving GET variables to a page). If you made the correct web service call, it will respond you with an XML page containing the information you’ve asked. An example: http://www.somecompany.com/webservice/?searchuser=yoursearchstring if the user of the string exists the xml will be something like this: yoursearchstring The web service responds and says, I’ve found a user with that username. You can check the stat=”ok” parameter. If the web service didn’t found a user with your search string it will respond something like this: stat=”fail”, with the error message “User not found”. Your only task, as a programmer, is to catch that xml and parse it to usable data. And that’s all there is to it. Yes, it’s as simple as that. Source --> http://www.bornontheweb.be/2006/03/01/rest-web-service-a-flickr-tutorial/