Introduction:
A web service that communicate with service consumer using the principles of rest architecture is Rest Web service. Now we should know what is rest architecture. Even e have already covered about SOAP vs REST and the Rest service development using jersey which is major Implementation of Rest in Java programming language.
REST stands for Representational State Transfer. Rest is an architectural set of specifications that makes a web service scaleble, flexible, modifiable and faster. In rest terminology data and functionality provided by service are called resources and any service client can access that resource using a unique URI. Service calls also can act upon resource using standard methods. Rest request and responses are supposed to use the stateless protocol for transmission of data, particularly HTTP.
Principles of Rest Services:
Uniform Interface:
In the rest architecture everything is resource. Everything means a document, picture, Video or even module, class, method in the service program that is available to service consumer. The consumer can access any resource using just URI. REST make explicit use of HTTP methods to perform different operations in resources. We can delete a resource using DELETE method of HTTP protocol. Similarly we can use GET, POST and PUT to access, add and modify resources. Most Important as well best thing about rest is you can perform different operation on resources using different HTTP methods but with same URI. So you can relate the HTTP methods as verbs and resources as nouns.
Second thing is the resources have some representations like XML, JSON, text or TEXT and we can modify the representation as per our requirement. Client can select the resource representation. REST request and responses are self descriptive that means these not only contain data but also contain information like whether it should be cached or not, authentication required or not etc.. This principle of rest architecture is also known as address ability.
So In conclusion there must be a unique URI for a resource in web service. Naming conventions for uri is same as the normal web uri. I want to let you understand through small example. Lets suppose we have a resource which have information of the students. So in normal way we have /getstudentInfo URI to access the student information and /addstudentInfo uri to add the information of new student. But According to REST you can use a single URI for student information resource like /studentInfo. Here You can get information with the same URI with get HTTP method and add information using POST HTTP method. So there is a single URI for single resource.
Statelessness:
It is very simple concept. Stateless in REST means server do not store any information about client session information. This makes server more scalable and reduce work load. You may think being statelessness is odd for this time but if you look back one and half decades back servers not used to store session data. Fat clients send the necessary state related data with each request. Same thing we can implement in REST API. If server need client session data, then client will send that data with subsequent request.
Use of cache:
Server can use the cache to save the frequent response to reduce load. Caching is possible using cache, proxy or reverse cache therefore any coming request will go through these cache. GET requests are most supposed to be cached. But we can not cache put and delete methods. We rarely cache the responses for POST requests. In the cached responses header may contain information about date of response generation, expire date, a flag to represent change in resource and etc. It is a good practice to cache the static contents like images and graphics content, CSS or JavaScript files. We should not set expire date very high. If you are caching dynamic content, Expire time should be few hour. Use of cache reduce bandwidth, latency as well as load on server.
Layered System:
Rest allows the series of servers and hide this from service consumers. For example You can keep API s in a server, Database in another server and authentication system in separate server. Client do not knows the numbers of servers that responses come through.
Code on Demand:
This term has relation with representation. We can ask for JSON, XML or YAML from server. If client is Ajax or JS it may need json, Or if client is JAVA based it may require XML and if client program is written in ruby then they may require YAML. You may surprised that client can ask for different representation of the resources without changing the URI. Client send the media type with request header to specify for the required representation of resource. You can add header Accept and pass representation values like application/XML or application/json with it.
HATEOAS:
HATEOAS stands for Hypermedia As The Engine Of Application State. Just like you get hyperlinks as response to change the state of browser, Its possible to get hyperlinks in rest response to change the state of client application. Generally XML based REST services follow the syntax from Atom. Atom is XML based document format. Now we can publish a main URI to users and That service can return other service resource URIs on response. So this makes transparency in the resources. Another advantage of using HATEOAS is that we can reduce application state transition errors. Error codes are not always sufficient to know that what happened in the resource. So in such case we can send links with error information. It even decouple the information about client server interaction.
It is my brief explanation about REST architecture. These all are not exactly the specification from Roy Fielding. I have explain the each topic you may have heard about REST. Please do suggest or ask in comment below.
