REST is the acronym of Representational State Transfer that represents a set of principles for creating distributed applications in web. It was first introduced and defined by Roy Fielding in the year 2000. Unlike the traditional RPC-style SOAP services that uses HTTP just as a transport layer, REST uses all the advantages of the HTTP like request verbs, URI, media-types, caching, security etc. Since REST services works like a normal website they are easy to create and consume compared to the RPC-style web services. Some of the famous REST services on the web are Amazon’s Simple Storage Service (S3), Sun Microsystem’s Cloud service, Atom Publishing Protocol etc.
In this article we will see about what are HTTP request methods and how we should use them for REST services.
A browser uses a HTTP method whenever it sends a request to the server. There are different types of HTTP methods. The most popular and widely used HTTP methods are GET and POST. When you type a website url in the browser address bar ex. http://www.prideparrot.com actually you are issuing a GET request to the server and when you are making a payment through an online form you are making a POST request to the server. The HTTP protocol not only contains these two methods but it also contains other methods like PUT, DELETE, HEAD and OPTIONS.
On creating any REST service the way these request methods are being used is very crucial and that is one of the main discipline in REST that separates it from the traditional web services.
The GET method is used for getting data from the server. The data may be anything a HTML document, an image, XML file etc.
GET www.prideparrot.com HTTP/1.1
According to the HTTP standard the GET request should be used only to fetch some information from the server. Issuing the GET request should not change the state of the server. Here the state means it may be either a database or a file or anything. Issuing a GET request should not make some important change in the server. Unfortunately many websites and web services uses the GET method for other purposes like adding a new comment, deleting a blog post etc. that changes the state of the server.
GET www.prideparrot.com/comment/add?description=blah!blah!blah! HTTP/1.1
GET www.prideparrot.com/post/delete?id=21 HTTP/1.1
In REST services you should always use GET request to only return data not for adding, modifying or deleting.
The POST method is the powerful method in the HTTP protocol. It can be used for any operation and it is totally depend upon the server. A POST request can be used to create a new resource or to update an existing resource in the server. Most of the times the POST request is confused with the PUT request in terms of which CRUD operation it should perform on the server. The truth is both can be used to create as well as update operation but the difference comes in idempotency. If a request is said to be idempotent then how many times that request is issued serially the change is same as what happened in the first request. PUT request is idempotent while POST is not. In otherwords every time you issue a POST request the state of the server can be changed and that makes POST request should be issued carefully. A typical example is posting a comment to a blog when you click the submit button twice then you would likely created two comments in the server and for every new POST request a new comment is posted to the server. In REST architecture the POST is more linked with the create operation.
A typical POST request will looks like below.
POST www.prideparrot.com/blog/addcomment HTTP/1.1
Unlike the former two requests this is not so widely used. Suppose on client request you are performing some action on the server and the state of the server has to be same in the next requests then you can go for PUT. For ex. when you upload a file for the first time a new file is created in the server and the state of the server has been changed. If you again try to upload the same file the old file has to be replaced by the new one instead of creating another one. Unlike POST, a client can issue this request safely two or more times because the state changed in the server should be same as in the first request. PUT is more linked with the update operation but that has not to be the case always.
As the name the delete method should be used to remove or delete something from the server. For ex. to delete a row from database table or remove a file from file-system etc. Sometimes people wrongly use GET or POST to do that but you are creating a service and want to say it is completely RESTful then you should use DELETE method for that.
This request method is not widely used and it is used to fetch only the response header information from the server. This method is much similar like GET, should not change the state of the server but returns only the metadata information. This HEAD request method can be used to know whether a particular resource exist in the server or not or to know information about the resource. The difference between the GET and HEAD request methods are the former one returns the entity body but the later not.
This method is also not widely used. When you are creating a REST service and to return what are the operations that can be performed on a particular resource you should use this method. If a resource is read-only then issuing this request method on that resource returns a response header named Allow with the values GET and HEAD.
Allow: HEAD, GET
GET, HEAD and OPTIONS are called as safe methods. Because issuing these requests should not change the state of the server. In designing REST services this should to be taken care.
GET, HEAD, PUT and DELETE request methods are idempotent. Idempotent means how many times these requests are applied serially to the server the result is same as the intial request. If you are deleting a resource or data through DELETE request, when you issue the request at the first time the resource is removed from the server and if you again issue the same request nothing new should happen in the server i.e the state of the server should not be changed. The same rule applies for other requests also. When you are designing RESTful services idempotence should also be considered for these HTTP methods.
In this article we have seen about the various request methods (verbs) in HTTP. To create a service that is completely RESTful you should use them wisely as represented by the HTTP standards.