RESTful Web Services

RESTful web services are REST architecture based web services. REST is a resource based architecture in which services are light weight, highly scalable and maintainable. They are very commonly used to create APIs for web based applications.


This blog is designed for software professionals who are willing to learn RESTful web services. It will give basic understanding of its concepts and features.

What is REST?

REST stands for REpresentational State Transfer. It is a web standards based architecture and uses HTTP(s) protocol for data communication. In REST architecture, a REST Server simply provides access to resources and REST client accesses and present the resources. Here each resource is identified by URLs/ global IDs. It uses various ways to represent a resource like text, JSON and XML. Nowadays JSON is the most popular format being used in web services.

Web service will be hosted in a centralized location, which will be connected to the database server to serve client request. Service does not have any idea about which client is going to call, that means it is independent of client. Above image depict different types of client calling single service. Web services based on REST Architecture are known as RESTful web services. The following principles encourage RESTful services to be simple, lightweight and fast.

1. Stateless interaction

Every interaction with a resource is stateless. That means request messages are self-contained. Stateful interactions are based on explicit state transfer. By stateless it means that the server does not store any state about the client session on the server side. The session is stored on the client side. The server is stateless means that every server can service any client at any time, there is no session affinity. The relevant session information is stored on the client and passed to server as needed. That is where the State Transfer in REST comes from.

2. Resource identification through URL

A RESTful web service exposes a set of resources that identify targets of the interaction with its clients. Resources are identified by URLs, which provide a global addressing space for resource and service discovery.

3. Uniform Interface

Resources are manipulated using a fixed set CRUD (Create, Read, Update and Delete) operations. This is achieved using sets of HTTP methods. Followings are well known HTTP methods are commonly used in REST based architecture.

4. Content Negotiation

The HTTP specification defines content negotiation as “the process of selecting the best representation for a given response when there are multiple representations available.” In simplest words, it means return response in a format requested by client. Following request headers are used for content negotiation Accept: Which media types are acceptable for the response, such as “application/json”, “application/xml”, or a custom media types such as “application/vnd.example+xml” Accept-Charset: Which character sets are acceptable, such as UTF-8 or ISO 8859-1 Accept-Encoding: Which content encoding are acceptable, such as gzip Accept-Language: The preferred natural language, such as “en-us”

HTTP request
Get http://locachost:6655/api/products/1 HTTP/1.1
Host: localhost:6655
Accept: application/json, text/javascript, */*

HTTP response
HTTP/1.1 200 Ok
Content-Type: application/json; charset=utf-8
Content-Length: 57
Connection: Close

“Id”: 1, “type”: “Apple”, “Category”: “phone”, “Price”: 159.99

In this example, the client requested either JSON, Javascript, or “anything” (*/*). The server responded with a JSON representation of the Product object. Notice that the Content-Type header in the response is set to “application/json”.


1. Simplicity: REST services can be accessed from any browser. 2. Lighter on Bandwidth: Less data is transferred over network with serialized json/xml data format. 3. Security: REST application security rules can be setup using the http standards. The administrator (or firewall) can discern the intent of each message by analyzing the HTTP command used in the request. For example, a GET request can always be considered safe because it can’t, by definition, modify any data.


1. REST requests (especially GET method) are not suitable for large amount of input data. 2. REST doesn’t cover all web services standards, like Transactions, Security, and Trust 3. REST service only support http(s) protocol. Because of this it only secure end to end transport channel, it does not support message level security.


This blog has provided basic concept of RESTful web service, service behavior and purpose of the service. It can be implemented when we plan to design an application to be used exclusively on the web, and also when we need a quick client integration. One should try to avoid using REST when application is service oriented architecture which interconnects many systems and uses many transport channels.

ADROSONIC and Riversand Partner to Deliver Cloud-native MDM and PIM Solutions for the Insurance Industry ​ Know More