Representational State Transfer (REST) is a technical description of how the World Wide Web works. If we imagine the Web as a device with its own operating system, its architectural style would be REST. A REST Application Programming Interface (REST API) is a type of web server that allows both user-operated and automated clients to access resources that model a system’s data and functions. A well-designed REST API encourages developers to adopt the web service. Today, it has become an essential feature of modern systems. But how can you define that an API is RESTful? This architecture outlines six constraints, and we will explain each of them below.
Uniform Interface
The uniform interface is fundamental to any RESTful service. It defines how clients and servers interact. Moreover, it ensures consistency and clarity across the system. The four guiding principles of the uniform interface are:
- Resource-Based: Individual resources are defined using URIs and are separated from the responses returned to the client.
- Manipulation of Resources Through Representations: When a client receives a resource’s representation, including metadata, it can modify or delete the resource if it has permission.
- Self-descriptive Messages: Each message contains enough information to describe how to process it. Responses also specify whether they can be cached.
- Hypermedia as the Engine of Application State (HATEOAS): Clients send state via body content, parameters, headers, and URI. In response, services return state via headers, body content, and status codes.
Client-Server
This constraint separates the user interface from data storage. As a result, client code becomes portable, and servers become more scalable. Developers can independently update servers or clients as long as they maintain the interface.
Stateless
Each request from a client must contain all necessary information. The URI identifies the resource, and the body conveys its state. Once the server processes the request, it returns the appropriate response using headers, body content, and status codes. Therefore, servers do not retain client state between requests.
Cacheable
Responses must indicate whether they can be cached. Properly managed caching reduces server load and improves performance. For example, a cached response can eliminate redundant client-server interactions.
Layered System
Clients usually cannot determine whether they are connected directly to the end server or an intermediary. Intermediate servers enhance scalability through load balancing and caching. Additionally, they enforce security policies across layers.
Code on Demand
This is the only optional constraint. Servers can send executable code—such as Java applets or JavaScript—that extends or customizes client functionality. As a result, clients can adapt behavior dynamically without modifying their core systems.
Conclusion
To sum up, if any constraint (except Code on Demand) is violated, the system is not fully RESTful. When all six constraints are followed, the REST architecture provides a scalable, flexible, and powerful design for distributed hypermedia systems.
To learn more about RESTful APIs, visit the RESTful API design guide.
Read also: What is an API and How it Works
