REST APIs are one of the most widely used architectural approaches for connecting services on the web. REST stands for Representational State Transfer, a term introduced in 2000 by Roy Fielding as part of his doctoral dissertation at the University of California, Irvine. His work laid the foundation for a simple and scalable model that continues to shape how distributed systems and modern web applications are built today.
A RESTful API is not defined by a specific protocol or standard. Instead, it is an architectural style that follows a set of guiding principles. These principles describe how software components should interact over the web, using uniform and predictable interfaces.
Core principles of REST architecture
The value of REST lies in its simplicity and adaptability. A well-designed RESTful system is built around several key properties that improve how software components interact, evolve, and scale. These include:
- Performance: how well components communicate under different conditions
- Scalability: support for many components or requests simultaneously
- Simplicity: clarity in how components exchange information
- Modifiability: the ability to update components easily
- Visibility: transparency in system behavior and communication
- Portability: flexibility in where and how components run
- Reliability: resilience against system-level failures
These properties are supported by specific architectural constraints that guide how REST APIs are structured and used.
Architectural constraints of REST
REST APIs follow a set of architectural rules that give them structure, predictability, and flexibility. These constraints are what make REST scalable and reliable across different systems and teams.
Uniform interface
This constraint ensures that all API interactions follow a consistent format, which makes it easier for different components to work together. The uniform interface is one of the core ideas behind REST. It includes four key principles:
- Resource identification: Every resource is identified using a URI, or Uniform Resource Identifier, such as
https://api.example.com/users/123. A URI is often a URL, but it can also refer to other identifiers. The key is that it uniquely points to a specific piece of data in a way that any system can understand.
- Resource manipulation: Clients can update or delete resources if they have the right permissions. When a client receives data from an API, it should also know how to send changes back if needed.
- Self-descriptive messages: Every request and response should contain all the information needed to understand it. For example, the HTTP method, headers, and body together describe exactly what the message does.
- Hypermedia as the engine of application state: APIs should guide clients by including links to possible next actions. This means clients do not need to hardcode paths or actions. Instead, they can discover valid options dynamically through each response.
Client-server separation
REST separates the frontend and backend responsibilities. The client is responsible for the user experience, while the server handles data, business logic, and processing. This separation allows developers to update or scale either side independently without affecting the other.
Statelessness
Each API request must contain all the information needed to complete the operation. The server does not store anything about the client's state between requests. This simplifies the architecture and makes it easier to scale, because each request is handled on its own.
Cacheability
To reduce unnecessary traffic, responses must indicate whether they can be cached. If a response is marked as cacheable, the client can reuse the data instead of requesting it again. This improves speed and reduces load on the server.
Layered system
REST supports the use of intermediary systems such as proxies, gateways, or load balancers between the client and the server. These components can improve performance, security, or scalability. Clients should not need to know whether they are interacting with the actual server or with an intermediary.
Code on demand
This is the only optional constraint in REST. In some cases, a server may send executable code to the client to extend its functionality. For example, a server could return JavaScript that the client runs locally. Although not required, this can be useful for customizing client behavior in specific contexts.
REST and HTTP methods
REST APIs typically use standard HTTP methods to perform actions on resources. These methods are widely understood and form a consistent vocabulary for interacting with services:
- GET retrieves a resource without modifying it
- POST creates a new resource
- PUT updates or replaces a resource
- DELETE removes a resource
- PATCH makes a partial update to an existing resource
Each method is used in combination with a URI that identifies the resource in question. Together, these form the foundation for most RESTful interactions on the web.
Why REST became so widely adopted
REST was developed in parallel with HTTP and the URI standards that drive the modern web. Because of this, it integrates naturally with the infrastructure and technologies already in place. Its simplicity and flexibility have made it the default choice for web-based APIs and services.
Rather than requiring a specific language or framework, REST focuses on how components interact. This makes it easier to design and maintain systems that are scalable, testable, and resilient.
By emphasizing stateless communication, a uniform interface, and a resource-based model, REST supports a range of use cases from small websites to enterprise-scale applications.