REST stands for Representational State Transfer. It is an architectural style for designing networked applications that relies on stateless, client-server communication, typically over HTTP, where resources are identified by URLs and manipulated using standard HTTP methods. REST provides a set of constraints for designing networked applications that are scalable, maintainable, and performant. When these constraints are applied to web services, they create RESTful APIs, which have become the dominant style for building web APIs due to their simplicity, scalability, and alignment with HTTP's native capabilities.
It is an architectural style, not a protocol or standard, created by Roy Fielding in his doctoral dissertation in 2000.
Client-Server: The client and server are separated concerns. The client handles the UI/UX; the server handles data storage and business logic. This separation allows each to evolve independently. This improves portability and scalability.
Stateless: Every request from the client to the server must contain all the information needed to understand and process it. The server stores no session state between requests — each call is self-contained. This simplifies server design and improves reliability.
Cacheable: Responses must label themselves as cacheable or non-cacheable. When cacheable, clients (and intermediaries) can reuse responses, reducing server load and improving performance.
Layered System: The client doesn't need to know whether it's talking directly to the server or an intermediary (like a load balancer, cache, or gateway). Layers can be added or removed transparently, improving scalability and security.
Code on Demand (optional): Servers can extend client functionality by transferring executable code (like JavaScript) to run on the client. This is the only optional constraint in REST.
Uniform Interface: A consistent, standardized interface between components simplifies the architecture. This is achieved through four sub-constraints: resource identification in requests (URIs), resource manipulation through representations, self-descriptive messages, and hypermedia as the engine of application state (HATEOAS). The cornerstone of REST, this constraint simplifies and decouples the architecture through four interface constraints: resource identification, resource manipulation through representations, self-descriptive messages, and hypermedia as the engine of application state (HATEOAS).
Resources: Everything in REST is a resource, which is any information that can be named (users, documents, images). Resources are identified by URIs (Uniform Resource Identifiers).
HTTP Methods: REST uses HTTP methods to perform operations on resources: GET (retrieve), POST (create), PUT (full update), PATCH (partial update), DELETE (remove).
Representations: Resources are manipulated through representations (JSON, XML, HTML). The client and server exchange these representations, not the actual resource itself.
Stateless Communication: Each request is independent; no client context is stored on the server between requests. All state required to process the request is included in the request itself.
Hypermedia (HATEOAS): Hypermedia as the Engine of Application State means that responses contain links to related resources, allowing the client to discover available actions dynamically.
Use nouns in URLs (not verbs):
/api/usersnot/api/getUsersUse plural nouns for collections:
/api/productsrather than/api/productUse HTTP status codes correctly: 200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Internal Server Error
Version your API:
/api/v1/usersto allow for future changes without breaking existing clientsUse query parameters for filtering, sorting, and pagination:
/api/posts?status=published&sort=-createdAt&page=2&limit=20Return appropriate error messages with consistent structure
Use SSL/TLS (HTTPS) for all communications
The key insight of REST is that it treats the web as a distributed hypermedia system. Resources are identified by URIs, manipulated through their representations, and linked together through hypermedia. When a REST API is fully hypermedia-driven (HATEOAS), clients need only know the initial entry point; all subsequent actions are discovered through links in the responses. This reduces coupling between client and server and allows the API to evolve without breaking clients.