REST
Representational State Transfer. An architectural style for designing networked applications using stateless, client-server communication over HTTP.
Detailed Explanation
REST is not a protocol or standard—it is a set of architectural constraints that, when applied as a whole, emphasize simplicity, scalability, and modifiability. A RESTful API uses standard HTTP methods (GET, POST, PUT, DELETE) to perform operations on resources identified by URLs.
Key principles include statelessness (each request contains all information needed to process it), uniform interface (consistent resource identification and manipulation), cacheability (responses can be cached), and a layered system (clients cannot tell if they are connected directly to the server or through intermediaries). REST has become the dominant API architecture on the web, used by companies from Google to Netflix.
Why It Matters
REST is the most widely used API architecture. Mastering REST patterns is fundamental to building and integrating modern web services.
Real-World Example
The GitHub API uses REST: GET /repos/{owner}/{repo} retrieves a repository, POST /repos creates one, PUT /repos/{owner}/{repo} updates it, and DELETE /repos/{owner}/{repo} removes it.
When to Use
When building web APIs that need to be simple, cacheable, and widely accessible. REST works well for CRUD operations, resource-oriented architectures, and public APIs.
Advantages
- Simple and well-understood
- Excellent caching support via HTTP
- Wide tooling and library support
- Scalable stateless architecture
- Works well with HTTP/2 and CDNs
Disadvantages
- Over-fetching or under-fetching data
- Multiple round trips for complex data
- No built-in real-time capabilities
- Versioning can become complex
- Less flexible query patterns than GraphQL
Related Terms
Frequently Asked Questions
What makes an API RESTful?
A RESTful API must follow these constraints: client-server architecture, statelessness, cacheability, uniform interface, layered system, and optionally code on demand. Most importantly, it uses HTTP methods correctly on resource-oriented URLs.
What is the difference between REST and SOAP?
REST is an architectural style using HTTP and JSON, while SOAP is a protocol with strict standards, XML messaging, and built-in security features. REST is simpler and more flexible; SOAP is more formal with ACID compliance guarantees.
How do I handle errors in a REST API?
Use standard HTTP status codes: 200 for success, 201 for created, 400 for bad request, 401 for unauthorized, 404 for not found, 500 for server errors. Include a consistent error response body with a machine-readable code and human-readable message.
What are REST best practices?
Use nouns for resources (/users not /getUsers), plural names (/users not /user), HTTP verbs for actions, version your API, use pagination for lists, return appropriate status codes, and document your API with OpenAPI/Swagger.
When should I NOT use REST?
Consider alternatives when you need real-time bidirectional communication (use WebSockets), complex queries with nested data (consider GraphQL), or event-driven architectures (use webhooks or message queues).