Introduction to REST

Sir Tim Berners-Lee invented the World Wide Web in 1989. In the past three decades, the Web has evolved a lot, and most of the Millennials and Post-Millennials see it as an intricate part of their daily life. Ever wondered how the world wide web became so successful? Why has the Internet become so viral?

Roy Fielding, the same person behind Apache HTTP Server, thought in these areas way back in the year 2000 and wrote about it in his thesis work “Architectural Styles and the Design of Network-based Software Architectures” during his Ph.D. days. He identified the specific architectural principles that answered:

  • Why is the web so prevalent and ubiquitous?
  • Why is the web scalable?
  • Can we apply the principles in our applications?

In this thesis, he coined the term REST. REST stands for Representational State Transfer.

Architectural Principles of REST

Let us understand the important architectural principles of REST proposed by Roy Fielding.

Addressable Resources

Everything in REST interface is a resource or an item. Each resource shall be addressable via a URI (Uniform Resource Identifier). When you request information via a web browser, you are typing in a URI. Each HTTP request would contain the URI of the object from which you are getting information from or posting information to.

A typical URI will have the following format:


Protocol in the case of RESTful web services is usually HTTP or HTTPS. ‘Host’ is the Fully Qualified Domain Name(fqdn) or IP Address. If our REST layer is not specifying a separate port number in its server configurations, we can specify port number as optional as the default port for HTTP is port number 80.

Path expression will be seen after host and port. Each text segment inside the path expression is delimited by a “/”. The path can be synonymous to directory structure that we usually see inside a Windows or Linux environment. A question mark usually separates the path from a query string that may follow the path. A query string is nothing but a list of parameters represented as name/value pairs. Consider the example:

In the above URI, you are asking for the list of all employees who work in HR department in AsiaPacific region. Note that an ampersand (&) is used to separate the query strings from each other.

The last part of a URI is the fragment. It is delimited by a pound (#) symbol. It is usually used to point to a particular place inside the document that you are querying for.

Sometimes, we may have special characters that need to be encoded properly so that the URI is not broken. In such cases, we can use percent encoding. A percent encoding is nothing but replacing the unsafe special character by %ascii_value_of_character. To quote an example, space is usually replaced with ‘%20’.

Uniform, Constrained Interface

REST interface uses a small set of well-defined methods of the HTTP protocol to manipulate the resources. There are certain reasons why Roy Fielding suggested constraining the interfaces:

  • From a given URI, we usually get to know what methods are supported for that resource. Unlike SOAP which heavily relies on a WSDL that defines the services and stubs created from it, REST interfaces can be invoked and used simply via the HTTP methods like GET, PUT, POST and DELETE.
  • Most programming languages have an HTTP client library which makes it easier for the different programs to be interoperable. Unlike CORBA, we don’t need vendor specific libraries to be installed so that the REST services can be consumed at the client end.
  • Using constrained and well-defined methods of HTTP, we can always predict the behavior while the system scales up. This can lead to incredible performance benefits in the long run.

Representation-oriented Services

RESTful web services allow us to interact and get the resource in different formats. This concept was introduced because different applications consume data in different formats. Eg: Browsers usually need HTML, JavaScript needs JSON data, a traditional programming language like C++ or C# may require data in XML format. To support interoperability, a REST interface may provide the output in required format as suggested by the REST client using the accept headers specified in the incoming HTTP request.


Statelessness here refers to the fact that no client session data shall be stored at the server end. The server manages the state of the resources alone which it exposes. Sometimes, the client may need to use and save session data for its reasons. In such cases, the session based cookie data will be saved at the client end.

Roy Fielding had put a big emphasis on statelessness of RESTful interfaces because it would be easier to scale a stateless interface as all you need to do is add machines in case of a clustered environment.


The fifth principle of REST is the usage of Hypermedia As The Engine Of Application State (HATEOAS). A rest client need not have any particular knowledge about the REST server apart from a general understanding of Hypermedia.

Hypermedia is a term used to refer to diverse types of interlinked and nonlinearly accessed data in various media formats available over the world wide web. It is an extension of hypertext. One of the advantages of using hypermedia and hypertext in RESTful interfaces would be to create complex sets of information gathered from diverse sources. The information, thus created, could be a combination of date available in a company intranet or information disseminated all over the internet. In case of a RESTful server’s response, the response body may contain extra links embedded so that additional information can be queried for as needed.

A classic example of this would be responses that we see for queries on products made on any web store. A REST service which shall give data on the products sold by the web store will usually have the following format:

Note that we should be able to get the details of the book named “The C programming language” by issuing a subsequent GET call to the URL formed by concatenating current URL and URI specified in the response body under <product> tag.


SOAP and other RPC-based mechanisms like CORBA used to be the preferred mode of data exchange between applications before the concept of REST came into existence. The problem with the predecessors of REST was that they used to make the technology stack heavier than necessary. REST offers a simple, flexible, interoperable and efficient way of writing web services.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.