Why this blog?
This blog highlights REST Best Practices intended for the developers who are interested in creating RESTful web services which provides high reliability and consistency across multiple service suites. We all know there are various resources on best practices for creating RESTful webservices. However it should also be known that many of the available resources are conflicting. Also, it’s likely not doable to refer, read and comprehend several books on this subject with a motto of implementing services “tomorrow”. This blog will enable you to quickly understand and grasp RESTful concepts with major concern on best practices and conventions.
What is REST?
REST is abbreviation of Representational State Transfer. REST represents the architectural style of World Wide Web (WWW). REST is and approach to communication which makes simple HTTP calls for inter-machine communication. REST is often preferred over SOAP because REST does not use as much bandwidth as heavyweight SOAP does which makes it a better option for use over the Internet.
In REST, the calls will be message based and dependent on HTTP standards to describe these messages. REST can be understood as a simple request/response mechanism, where each request returns a response. The following fig. will give you a better idea:
RESTful API’s, more popularly termed as REST API’s are the web services written using REST architecture.
REST is resource based. When we talk about REST, it indicates things or resources as opposed to actions in SOAP. In RESTful services noun represents the resources, for example a person resource, a user resource. We use a HTTP verb (POST, PUT, GET, DELETE, etc.) to indicate what operation the REST API has to perform. Resources are identified by the URIs. It is possible to have multiple URIs pointing to same resource. RESTful API’s generally accept/return data in json or xml format.
Let’s quickly form an example with this basic knowledge before moving further. Suppose Sagar is a resource, there is a service to fetch contact information using the HTTP verb GET which will return the data like name, address, phone number, email address in JSON or XML form
REST architectural style defines following six constraints:
1. Uniform Interface
5. Layered System
6. Code on Demand
Let’s have a small review of each:
1. Uniform Interface:
It defines the interface between clients and servers. Uniform Interface simplifies and decouples the architecture. It enables each part to develop or evolve independently. Uniform interface describes the following four guidelines or principles:
It is not required for the webserver to remember the client’s state. The necessary state required to handle the request is included in the request itself, whether as part of URI, query-string parameters, body or headers.
Clients can cache responses. Therefore Responses must explicitly or implicitly define themselves as cacheable or not which prevent the clients from reusing stale, old or inappropriate data in response to further requests.
The uniform interface is responsible to separate the clients from the servers. Servers and clients can be developed independently. It conveys that the clients are not concerned with data storage which is internal to each server, which increases the portability of the client code. Servers are not concerned with the UI or user state, which makes the servers more scalable and simpler.
5. Layered System:
A client is unable to tell if it is connected directly to the end server or to an intermediary server. Intermediary servers may improve system scalability by providing shared caches and enabling load-balancing. Security policies can also be enforced through layers.
6. Code on Demand:
HTTP Verbs/ Request Methods:
Clients specify their desired interaction method in the Request-Line part of an HTTTP request message. Each HTTP method is bound to some specific, well-defined rules and meaning within the context of a REST API’s resource model.
The primary or most commonly used HTTP verbs or more properly called as methods are GET, PUT, POST and DELETE. These correspond to create, read, update, and delete operations respectively. OPTIONS and HEAD are the other verbs but are less frequently used.
The GET method is used to read or retrieve a representation of a resource. As GET method (along with HEAD) is used for READ only purposes hence they are considered safe as they do not change the data. GET (and HEAD) are considered as idempotent, i.e., making multiple identical requests end up having the same result as a single request.
We use PUT method mostly for update functionalities. Use this method for PUT-ing or updating data to a known resource URI along with the request body which contains the newly-updated representation of the original resource that we intend to change.
PUT method can also be used to create a resource in cases where resource ID is provided by the client instead of the server. But we must generally use POST to create new resources where the client defined ID is included in the body representation.
PUT is not a safe method, although it is idempotent.
POST method is utilized to create new resources. This method is not safe nor idempotent.
As the verb suggests, it is used to delete a resource identified by the URI.
Response Status Codes:
Forty standard codes have been defined by HTTP to convey the results of a client’s request. These codes can be divided into following five categories:
Let’s have a short and precise look over the success and error status codes.
HTTP response success codes: