RESTful Web Services

What is REST?

REST stands for REpresentational State Transfer. REST was first introduced by Roy Fielding in year 2000.

REST is a web standards based architectural design for networked hypermedia applications, it is primarily used to build web services that are lightweight, maintainable, and scalable. REST uses HTTP protocol for data communication (but REST is not depend on any protocol, but almost every RESTful service uses HTTP as its Underlying protocol).

In REST architectural style, data and functionality are considered resources and are accessed using Uniform Resource Identifiers (URIs)

What is RESTful Web Service?

A web service is a collection of open protocols and standards used for exchanging data between applications or systems. Web services based on REST Architecture are known as RESTful Web Services. These web services use HTTP methods to implement the concept of REST architecture. A RESTful web service usually defines a URI (Uniform Resource Identifier), which is a service that provides resource representation such as JSON and a set of HTTP Methods.

Features of a RESTful Services

In general, RESTful services should have following properties and features.

1. Representations

2. Messages

3. URIs

4. Uniform interface

5. Stateless

6. Links between resources

7. Caching

Representations

The focus of a RESTful service is on resources and how to provide access to these resources. A resource can easily be thought of as an object as in OOP.

1. Identify the resources and determine how they are related to each other. (Familiar to first step of designing a database, Identifying entities and relations).

2. Find a way to represent these resources in the system. We can use any format such as JSON, XML. Also we can use more than one format and decide which one to use for a response depending on the type of client or some request parameters.

A good representation should have following qualities.

1. Both Client and Server should be able to comprehend this format of representation.
2. A representation should be able to completely represent a resource. If there is a need to partially represent a resource, then you should think about breaking this resource into child resources. (Smaller representations means less time required to create and transfer them).
3. The representation should be capable of linking resources to each other. This can be done by placing the URI or unique ID of the related resource in a representation (more on this in the coming sections).

Messages

The client and service talk to each other via messages. Clients send a request to the server, and the server replies with a response.

HTTP request

Method : is the one of HTTP Methods , GET,PUT,DELETE,POST,OPTIONS

URL : is the URI of the resource on which the operation is going to performed.

Version : is the version of HTTP.

Request Header: contains the metadata as a collection of key-value pairs of headers and their values.

Entity Body/Request Body: is the actual message content. In a RESTful service, that's where the representations of resources sit in a message.

HTTP response

Version : is the version of HTTP.

Status Code :  This response code is generally the 3-digit HTTP status code.

phrase: which contains the status of the request. 

Response Header:  contains the metadata and settings about the response message.

Entity Body/Response Body: contains the representation if the request was successful.

URI

REST requires each resource to have at least one URI. A RESTful service uses a directory hierarchy like human readable URIs to address its resources. The job of a URI is to identify a resource or a collection of resources. The actual operation is determined by an HTTP verb. The URI should not say anything about the operation or action. This enables us to call the same URI with different HTTP verbs to perform different operations.

Important Recommendations for well-structured URI

• Use plural nouns for naming your resources.
• Avoid using spaces as they create confusion. Use an _ (underscore) or – (hyphen) instead.
• A URI is case insensitive.
• can have our own conventions, but should stay consistent throughout the service. Make sure your clients are aware of this convention. It becomes easier for your clients to construct the URIs programmatically if they are aware of the resource hierarchy and the URI convention you follow.
• A cool URI never changes.
• Avoid verbs for your resource names until your resource is actually an operation or a process.

Uniform Interfaces

RESTful systems should have a uniform interface. HTTP 1.1 provides a set of methods, called verbs, for this purpose. Among these the more important verbs are:

• GET – Provide a Read Only access to a resource.
• PUT – Used to create a new resource.
• DELETE – Used to remote a resource.
• POST – Used to update an existing resource or create a new resource.
• OPTIONS – Used to get the supported operations on resource.
• HEAD - Return only the response headers and no response body.

Statelessness

A RESTful service is stateless and does not maintain the application state for any client. A request cannot be dependent on a past request and a service treats each request independently. HTTP is a stateless protocol by design and you need to do something extra to implement a stateful service using HTTP. 

Links Between Resources

A resource representation can contain links to other resources like an HTML page contains links to other pages.

Caching

Caching is the Concept of storing the generated result and using stored results instead of generating them repeadly if the same request arrives in the near future.

Documenting a RESTful Service

RESTful services do not necessarily require a document to help clients discover them. Due to URIs, links, and a uniform interface, it is extremely simple to discover RESTful services at runtime. A client can simply know the base address of the service and from there it can discover the service on its own by traversing through the resources using links. The method OPTION can be used effectively in the process of discovering a service.

This does not mean that RESTful services require no documentation at all. There is no excuse for not documenting your service. You should document every resource and URI for client developers. 

I hope you understood the basic concept of the RESTful web services. in the next article I will Explain you how to Build a RESTful web Service with Spring boot.