Photo by bruce mars on Unsplash

The Constraints of REST

Bivás Biswas
Jun 27 · 9 min read

The Early Internet and Its Problems

What is the operating system of the Internet? There isn’t one. But, there is an architecture that the Internet follows so it can operate and achieve a massive amount of scale for millions and millions of …make that billions of users. That Architecture is called REST which stands for Representational State Transfer.

Why is REST Important

In the early 90s, the web started expanding. Like the Big Bang Theory, once it started it was unstoppable. It grew exponentially. Within the first 5 years of the Internet, the number of users grew to 40 million.

The growth was going to be unsustainable. The growth was outpacing the infrastructure that was necessary to support that volume of users.

There wasn’t a uniform protocol. Web technologies that provide us with stability today like caching, was missing at the time.

A few people set out to drive a standard. One such notable pioneer was Roy Fielding, the co-founder of Apache HTTP server project. He identified that there are some key constraints that the web needs to satisfy so it continues to scale without reaching a critical point of system breakdown.

The constraints of the web that Roy Fielding along with Tim Berners Lee and a few others came up with are -

  1. Client-Server

After this proved successful in continuing to maintain scalability of the Web, Roy Fielding made it into his Ph.D. dissertation and called this architecture encompassing these constraints REST.

What is REST API

The REST API is an Application Programming Interface that allows a client to access resources sitting on a server. These resources, at any given time, holds an accurate description of the system’s state.

There are many web APIs. How do you distinguish between just another web API and an API that is considered RESTful? If you’re developing a web API, how can you tell that you’re achieving RESTfulness?

Leonard Richardson wrangled with the same questions for years before coming up with a model — a metric that can be applied to measure the RESTfulness of a web API.

This metric came to be known as the Richardson Maturity Model. This model outlined 3 levels to the ladder to RESTful success. The levels starting from the lowest to highest are-

Level 1: URI

Level 2: HTTP

Level 3: Hypermedia

Each level captures one essence of the REST API. As a web API satisfies the requirements of each level, it levels up.

The API can then be ‘certified’ as a Level 1, 2, or 3 REST API.

I. Client-Server

The client and the server can have their own technology stack. How the server gets the job done is of no concern to the client and vice versa. When we flip the light switch we expect there to be light without concerning ourselves about how the electricity is being generated and being delivered to our homes. This is borrowed from the Software Engineering principle named Separation of Concerns. Wikipedia defines it as so-

In computer science, separation of concerns (SoC) is a design principle for separating a computer program into distinct sections, so that each section addresses a separate concern.

Separation of concerns allows for loose coupling. If a server goes down the request can be routed to a backup server and the client doesn’t need to know. The client and the server can continue to work together through this loose coupling as long as they adhere to the uniform interface.

II. Uniform Interface

Every resource on the internet can be accessed by a unique identifier. Like every home has a unique address in our world. In the digital world of information, every resource has a unique address.

In 1991, the inventor of the World Wide Web, Tim Berners Lee wrote,

The WorldWideWeb is a wide-area hypermedia information retrieval initiative aiming to give universal access to a large universe of documents

There are additional things that can be done while looking up a resource via its unique identifier.

For example, this unique identifier can be looked at with different lenses to look at the resource differently while the resource itself doesn’t change.

A client can request a JSON view of the resource and it’ll get a JSON representation. Alternately, the client can request an XML view of the resource and the server will serve up an XML representation.

Additionally, a client can request the server to update the resource by sending out a very specific message in the request body. It’s up to the server to then accept or deny the request.

To take into account these additional tasks that can be accomplished with a unique identifier, Fielding subcategorized the constraint of Uniform Interface into 4 different sub-constraints —

a. Identification of Resources

b. Manipulation of resources through representation

c. Self-descriptive messages

d. Hypermedia as the Engine of Application State (HATEOAS)

a. Identification of Resources

Tim Berners Lee’s vision is that every data in that universe can and should be referenced directly. Every resource should have a Universal Resource Identifier (URI). Tim Berner’s Lee wrote these two axioms for the URI, which is also commonly referred to as the URL (Uniform Resource Locator)-

Axiom 0: Universality 1

Any resource anywhere can be given a URI

Axiom 0a: Universality 2

Any resource of significance should be given a URI.

URIs are divided into schemes like HTTP, FTP, telnet, etc. Each one of these schemes has its own specifications. These specifications determine what kind of resources can be accessed via these schemes.

b. Manipulation of resources through representation

The representation which is the format of the resource and the resource itself are two separate things. Each resource can be represented in different ways. This separation allows different clients to request the resource in a way that is usable for them.

For example, a picture is a resource which contains an array of RGB values. These values can be represented in the form of a JPG or a PNG. Because the representation is an abstraction to the contents of the resource, new representations can be added later on from the same resource without having to duplicate the contents.

Axiom: Opacity of URIs

The only thing you can use an identifier for is to refer to an object. When you are not dereferencing, you should not look at the contents of the URI string to gain other information.

-Tim Berners Lee

c. Self-descriptive messages

Clients and Servers talk to each other using messages. The client makes a request. The server sends a response. Each request is a message and each response is a message.

Every message is self-descriptive which means that the messages being passed back and forth should have all the information required to complete the task.

This is also called a stateless system which we’ll touch on below. The messages are not expected to remember contents from other messages.

The messages have a header and a body. The header contains metadata that carries extra information about the message while the body contains the message itself.

In HTTP 1.1 specification there are 8 distinct message types that could be sent to an HTTP server. These distinct message types were called HTTP methods.








Out of these 5 are widely used today — GET, HEAD, POST, PUT, and DELETE

d. Hypermedia as the Engine of Application State (HATEOAS)

This is the most widely misunderstood REST constraint. People tend to believe that HATEOAS is the most important constraint and it is all of REST by itself. Nothing could be further from the truth.

Hypermedia is simply a link embedded in web components like pictures, and videos. Before hypermedia there was hypertext.

Hypertext was a string of characters that when clicked would navigate to a web page. Hypermedia extends navigation beyond just a string of texts. The term was coined by Fred Nelson in 1965.

For example, a user can navigate to an URL by clicking on the ‘submit’ button on a form. This was the POST method. By using hypermedia, the client can now request a change of state to a particular resource.

The form itself is a resource and the client gets the form by requesting it from the server using a GET method. Again, hypermedia is used here to set up for the request to change a resource. The server informs the client of a possible way to change the state of the resource.

The exchange and the accessibility of hypermedia between the client and the server are primarily responsible for changing the state of a resource and sharing the new state.

III. Layered System

The layered system constraint allows the architect to inject layers of service between the server and the client to efficiently serve the client request while the layering remains transparent to the client.

Common uses of layering is a load balancing system or a proxy server. Both of these are injected in between the client and the server.

The client makes the same request to the same URI but it is routed by a load balancer to a server that is immediately available and can process the client request right away thereby reducing latency.

Layering can also be used for caching.

Each injected layer in the system can only talk to the layer adjacent to it. In a classic 3-tier architecture there are 3 layers. The client, the application server and the database server. The client cannot talk to the database server directly as it’s not the adjacent layer.

Source: Wikimedia Commons

IV. Cache

Caching reduces latency and the load on the server. It increases the availability and reliability of the application.

With this constraint, the server can specify how the response can be cached by the client and/or by the different layers in the architecture.

For example, when the client is allowed to cache the data for a specified amount of time, the client may not contact the server for that same data within that time window.

If a user needs that data, the client will serve it from the browser cache which is sitting locally on the system. This cuts down on the round trip cost to the server and increases the responsiveness of the application.

Caching comes with an added complexity of managing the cache itself to avoid serving stale data.

V. Stateless

This constraint allows the web to handle the massive scale of the internet.

Each message from a client to the server should contain all the information necessary for the server to process the request.

The server is not expected to manage the state of the application. This allows the server to manage the resources while the client manages the application state.

Statelessness promotes session independence. Because of session independence, any server can process the client request. This makes load balancing possible.

The trade-off of statelessness is that it increases network bandwidth since every information needs to be passed in every request.

VI. Code-On-Demand

This is an optional constraint. The reason this is optional is that this constraint increases coupling between the client and the server.

This constraint enables the server to send in code in the form of scripts and applets to the client to execute. But, the client needs to know how to execute it. This is where the coupling comes from.

Some examples that leverage the Code On Demand (COD) constraint are Java applets and Flash.

The advantage of this constraint is that it enables the application to be extensible.

For example, this constraint can be leveraged to enable an application inside an organization to accept downloadable patches while blocking such downloads from the outside.


We studied the evolution of REST and how they play an instrumental role in providing scalability to the web.

Modern web services primarily follow the REST architecture. Every web service provides an application programming interface (API) for clients to communicate with its services. When the API adheres to the constraints of the REST we call it a REST API.

APIs have become a critical component of an Enterprise and has a direct impact on its balance sheet.

API is driving innovation in the business model. Pay attention to how you design, develop and grow your API. In the constraints of the REST is ingrained the scalability of the internet. Align your API with REST and unleash the same power within your organization.

Future Vision

A publication centered around high quality storytelling

Bivás Biswas

Written by

Harvard Business School. Former VP Engineering for AR startup. Former Computer Scientist for US Defense projects.

Future Vision

A publication centered around high quality storytelling

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade