REST

REpresentational State Transfer (REST)

What is REST?

REST architecutral style started as a model of how the web should work. How really web applications should work. ~ Roy T. Fielding

In a nutshell, REpresentation State Transfer (REST) is a software architecture that defines a set of rules for communication and data exchange between a client and a server. It is one of the methods for enabling communication in web applications, used for creating and managing them. REST imposes a specific design style on the system through a series of constraints in the context of communication over a network, which I will discuss later in the text.

History and purpose of REST

The origin of this architectural style lies in the specification of the HTTP protocol, for which Roy T. Fielding proposed the titular architectural style in his 2000 doctoral dissertation. It is important to note that HTTP is a protocol, while REST is an architectural style that utilizes this protocol.

The goal of REST during its creation was to develop a communication model that would be simple, efficient, and technology-independent, allowing applications to interact easily over a network.

REST is based on principles (referred to as constraints by the author) derived from the HTTP protocol, which is the most commonly used protocol for communication on the web.

REST Constraints

Note: These constraints primarily apply to backend developers who create APIs following the REST architecture principles, rather than to frontend developers who consume them.

There are many common perspectives on the software architecture design process. When designing REST architecture, emphasis was placed on restraint and understanding the system’s context. The process involved comprehending the needs of the system as a whole, without constraints, and then gradually identifying and applying constraints to the system’s elements.

So let’s start at the beginning.

1. Null Style

From an architectural perspective, the null style describes a system in which there are no distinguished boundaries between components.

As a starting point, we assume an empty set of constraints.

2. Client-Server (Separation of Client and Server)

There is a clear distinction between the application operating on the client side and that on the server side. The client need only know the full name of the resource it wants. The client sends requests, and the server responds, which enables greater scalability.

Advantages:

[Independence] The separation allows the components to evolve independently.

By separating user interface concerns from data storage concerns, we improve the portability of the user interface across multiple platforms and enhance scalability by simplifying server components. Most significantly for the web, this separation allows the components to evolve independently.

3. Stateless

Each request must contain all the information necessary for its successful completion, meaning that the server cannot store any information about the client’s state. Instead, the client provides a complete set of information with each request, enabling the server to determine whether the client has access to the requested resources.

Consequently, we add the following constraint to the Client-Server interaction: “communication must be stateless in nature.” This indicates that each request from the client to the server must include all the information necessary to understand the request and cannot rely on any stored context on the server. Therefore, the session state is entirely maintained on the client side, and every request is treated as an independent request.

Advantages:

[Visibilty] Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request.
[Reliability] Reliability is improved because it eases the task of recovering from partial failures.
[Scalability] Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn’t have to manage resource usage across requests.

Disadvantages:

[Network Performance] Decrease network performance by increasing the repetitive data (per-interaction overhead) sent in a series of requests, since that data cannot be left on the server in a shared context.
[Application Behavior Control] Application state on the client-side reduces the server’s control over consistent application behavior, since the application becomes dependent on the correct implementation of semantics across multiple client versions.

4. Cache

Next in order is cache component, which pops up network performance.

(Client - Cache - Stateless - Server)

A cache acts as a mediator between client and server in which the responses to prior requests can, if they are considered cacheable, be reused in response to later requests that are equivalent and likely to result in a response identical to that in the cache if the request were to be forwarded to the server.

Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests.

Advantages

[Efficieny] Partially or completely eliminate some interactions, improving efficiency and user-perceived performance.

Disadvantages:

[Reliability] Caching can decrease reliability if stale data differs significantly from what would have been obtained by sending the request directly to the server.

5. Uniform Interface

The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components. By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. Implementations are decoupled from the services they provide, which encourages independent evolvability. The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application’s needs. The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.

In order to obtain a uniform interface, REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.

Identification of resources: Each resource in a REST system is identified by a unique identifier, usually in the form of a URL. This ensures that operations are clearly tied to specific resources.
Manipulation of resources through representations: Resources are accessed or modified through their representations, such as JSON, XML, or HTML. Clients and servers exchange these representations without directly interacting with the resources themselves.
Self-descriptive messages: Messages in a REST system contain all the information needed to understand and process a request or response. This makes each message independent and self-contained.
Hypermedia as the engine of application state: Clients navigate the application using hyperlinks provided in the server’s responses. These links indicate available actions and the current state of the application, simplifying interactions with the system.s

6. Layered System

To meet Internet-scale requirements, REST adopts the layered system constraint, organizing architecture into hierarchical layers where each component interacts only with its immediate layer. This reduces system complexity, ensures independence between layers, and allows legacy systems to be encapsulated while shielding new services from older clients. Intermediaries can enhance scalability through load balancing and shared caches, offsetting potential overhead and latency. Placing shared caches at organizational boundaries improves performance and enables enforcement of security policies, such as firewalls. Additionally, REST messages, being self-descriptive, allow intermediaries to transform content dynamically, supporting flexible and efficient data flow.

7. Code-On-Demand (optional)

Code-On-Demand is an optional feature of the REST architectural style that allows clients to download and execute code, such as scripts or applets (deprecated), from the server. This approach simplifies client applications by enabling them to extend their functionality dynamically without requiring all features to be built-in initially.

In modern web development, the most common implementation of Code-On-Demand is through JavaScript, which powers interactive user interfaces and dynamic content loading. Frameworks like React, Angular, and Vue rely heavily on this mechanism. Other contemporary examples include WebAssembly (Wasm) for high-performance tasks and serverless functions, which dynamically handle server-side logic.

While Code-On-Demand enhances flexibility and scalability, it also raises security concerns, such as the risk of executing untrusted code. Modern techniques like Content Security Policy (CSP) mitigate these risks, ensuring safe execution. Though its use in traditional REST APIs is rare, Code-On-Demand remains a cornerstone of web interactivity and performance optimization today.

8. Style Summary

REST is built on a set of architectural rules chosen because of the specific benefits they bring to system design. While you can look at each rule on its own, it’s easier to understand why they were chosen by seeing how they are based on well-known architectural patterns. This connection helps explain the logic behind their use.

Summary

In this post, I explain what REST API is, outline its brief history, and present the set of constraints it was designed around. This is fundamental knowledge that every developer should possess. If you want to deepen your understanding, it’s worth exploring API terminology and trying to create your own project – nothing enhances skills like practice. Uncle Google will provide you with plenty of tutorials tailored to the technology you’re interested in.

Here are some practical links:

If you’re at an intermediate level and interested in more advanced topics, such as REST API security or building truly RESTful APIs, nothing broadens your understanding like digging deeper and exploring the subject on your own.