REST (Representational State Transfer) 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 stands for Representational State Transfer. It is an architectural style, not a protocol or standard, created by Roy Fielding in his doctoral dissertation in 2000. 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.
Client-Server: Separation of concerns between the user interface (client) and data storage (server). This improves portability and scalability.
Stateless: Each request from client to server must contain all necessary information to understand and process it. The server does not store any client context between requests. This simplifies server design and improves reliability.
Cacheable: Responses must explicitly declare themselves as cacheable or non-cacheable. Caching eliminates some client-server interactions, improving efficiency and scalability.
Layered System: The client cannot ordinarily tell whether it is connected directly to the end server or an intermediary. Intermediaries (load balancers, proxies) can improve scalability and security.
Code on Demand (optional): Servers can extend client functionality by transferring executable code (like JavaScript) to run on the client.
Uniform Interface: 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.