REST
REST is a stateless, resource-oriented architectural style that uses standard HTTP methods to interact with server resources identified by URIs.
REST APIs model everything as resources accessed via URLs. You use standard HTTP verbs — GET to read, POST to create, PUT/PATCH to update, DELETE to remove. Each request is stateless, meaning the server doesn't remember previous requests. Responses typically use JSON. REST is simple, widely supported, and works natively in every browser and HTTP client.
Strengths
- Universal browser and HTTP client support with zero additional tooling required
- Statelessness enables straightforward horizontal scaling behind load balancers
- Leverages existing HTTP infrastructure — caching, compression, TLS, proxies, CDNs
- Simple and intuitive resource-oriented mental model with a low learning curve
- Mature ecosystem of tools, documentation generators (OpenAPI/Swagger), and testing frameworks
- Works seamlessly with API gateways, WAFs, and observability tools
Weaknesses
- Over-fetching: endpoints return fixed data shapes, often including unnecessary fields
- Under-fetching: complex views require multiple sequential round-trips (N+1 problem)
- No built-in real-time or streaming capabilities — requires polling or supplemental protocols
- No native schema enforcement — requires external tools like OpenAPI for contract validation
- Text-based JSON serialization is less efficient than binary formats like Protocol Buffers
- Versioning can become burdensome as APIs evolve, requiring careful migration strategies
Technical Profile
Latency Profile
Typical REST API latency ranges from 20-200ms for simple CRUD operations depending on network distance, server processing, and database queries. HTTP/2 multiplexing improves performance for parallel requests. Cold starts on serverless platforms can add 100-500ms. CDN caching can reduce read latency to single-digit milliseconds for cacheable resources.
Payload Format
JSON/XML
Browser Support
Yes
Streaming Support
None
Schema Enforcement
Optional
Ideal Use Cases
- Public-facing APIs consumed by diverse clients (web, mobile, third-party developers)
- CRUD-heavy applications with well-defined resource models (e-commerce, SaaS platforms)
- Microservice APIs behind an API gateway with caching requirements
- APIs that need maximum tooling and ecosystem support
- Systems where horizontal scalability and statelessness are primary concerns
Real-World Examples
Payment processing API with exemplary REST design — consistent resource naming, idempotency keys, cursor pagination, and versioning via date-based API versions
REST API (v3) for repository management, issues, pull requests, and user data — complemented by a GraphQL API (v4) for flexible queries
REST API for SMS, voice, and communication services with clear resource hierarchy and webhook-based async notifications
REST API (v2) for tweet CRUD operations, user lookups, and timeline retrieval with OAuth 2.0 authentication
REST Admin API for store management, product catalog, and order processing with rate limiting and pagination
Likely Follow-Up Questions
- How would you handle API versioning for a REST API with thousands of active consumers?
- Compare cursor-based vs offset-based pagination — when would you choose each?
- How would you design a REST API to minimize the N+1 under-fetching problem without switching to GraphQL?
- What caching strategy would you use for a REST API serving both personalized and public data?
- How do you ensure backward compatibility when evolving a REST API's response schema?
Related Concepts
Source: editorial — Synthesized from Roy Fielding's dissertation, industry best practices (Stripe, GitHub API design guidelines), and common systems design interview patterns.