REST (Representational State Transfer) is the foundational architectural style for distributed hypermedia systems, originally formulated by Dr. Roy Fielding in his 2000 doctoral dissertation. It defines a set of architectural constraints that make communication between networked clients and servers standardized, stateless, performant, and horizontally scalable.
Figure 1.1: In REST architecture, the Client (frontend web browser, mobile iOS/Android app, CLI, or microservice) initiates an HTTP Request (specifying method, URL path, headers, and payload). The Server processes the request without maintaining client session state and returns a standardized HTTP Response containing a status code, response headers, and serialized data (typically JSON).
The 5 Guiding Architectural Constraints of REST
For an API to be considered truly RESTful, it must adhere to five mandatory architectural constraints:
-
🌐
1. Client-Server Separation: Complete decoupling of concerns. The client handles user interface rendering and state presentation, while the server manages persistence, validation, and business logic. Each can evolve independently across technology stacks.
-
🔒
2. Stateless Communication: Every individual request from client to server must contain all of the contextual information required to understand and authorize it (e.g., Bearer JWT tokens in the Authorization header). No client context or session state is stored on the server between requests.
-
⚡
3. Cacheability: Responses must explicitly declare whether they are cacheable or non-cacheable via HTTP headers (Cache-Control, ETag, Expires). Caching eliminates redundant round-trips to the origin server, drastically improving latency and bandwidth efficiency.
-
📐
4. Uniform Interface: Resources are universally identified using standard URIs (e.g., /api/v1/users/{id}), manipulated through standard HTTP representations (JSON, XML), and accompanied by self-descriptive metadata headers.
-
🏢
5. Layered Architecture: A client cannot tell whether it is communicating directly with the end application server or through intermediate proxies, CDNs, API gateways, or load balancers. Intermediate layers can enforce rate limiting, TLS termination, and caching transparently.
Core HTTP Verbs & Idempotency Rules
Operations on REST resources are mapped strictly to standard HTTP methods. Understanding their safety and idempotency guarantees is critical for designing robust distributed systems:
👈 Swipe horizontally to inspect full table 👉
| HTTP Method |
CRUD Operation |
Request Body Allowed? |
Safe (Read-Only)? |
Idempotent? |
Standard Status Codes |
Production Example |
GET |
Read / Retrieve |
No (RFC ignores body) |
Yes |
Yes |
200 OK, 404 Not Found |
GET /items?category=tech |
POST |
Create / Execute |
Yes (JSON / Form) |
No |
No |
201 Created, 400 Bad, 422 Error |
POST /items |
PUT |
Replace / Update |
Yes (Complete state) |
No |
Yes |
200 OK, 204 No Content |
PUT /items/101 |
PATCH |
Partial Modification |
Yes (Delta updates) |
No |
No / Conditional |
200 OK, 400 Bad Request |
PATCH /items/101 |
DELETE |
Remove / Destroy |
Optional (Avoid) |
No |
Yes |
204 No Content, 200 OK |
DELETE /items/101 |
💡
What does "Idempotent" mean in REST APIs?
An HTTP method is idempotent if making the exact same request multiple times produces the exact same server state as making it once. GET, PUT, and DELETE are idempotent (deleting item 101 ten times still leaves item 101 deleted). POST is not idempotent, because sending ten POST requests creates ten distinct records!
The 4 Classifications of REST APIs
In industry engineering, REST APIs are categorized based on their intended consumer audience and access boundaries:
🌍
1. Public / Open APIs
Published openly for consumption by external third-party developers without corporate restrictions. Examples include GitHub Public API, OpenWeather API, and Stripe Checkout.
🏢
2. Private / Internal APIs
Concealed within an enterprise infrastructure. Used exclusively for microservice-to-microservice communication, internal admin dashboards, and database orchestrators.
🤝
3. Partner APIs
Shared exclusively with vetted commercial business partners. Access requires explicit B2B mutual agreements, custom API keys, or mTLS certificates (e.g., banking gateways, logistics APIs).
🔀
4. Composite APIs
Aggregates multiple underlying microservice calls into a single synchronous response. Ideal for complex workflows like checkout pipelines (billing + inventory + shipping in one round-trip).
Architectural Comparison: REST vs GraphQL vs gRPC vs SOAP
Choosing the correct API paradigm is one of the most critical decisions in software engineering. Below is the comprehensive architectural comparison matrix:
👈 Swipe horizontally to inspect full table 👉
| Architecture Style |
Protocol & Transport |
Data Format |
Payload Flexibility |
Performance & Latency |
Best Suited For |
| REST (Fielding Style) |
HTTP/1.1 & HTTP/2 |
JSON, XML, Form-Data |
Fixed endpoint schemas |
High (with CDN caching) |
General Web APIs, Mobile Backends, Public Developer Portals |
| GraphQL (Meta) |
HTTP POST (Single /graphql) |
JSON |
Client specifies exact fields (zero over-fetching) |
Moderate (Complex server query parsing overhead) |
Complex Web & Mobile UIs with nested relational data trees |
| gRPC (Google) |
HTTP/2 Native (Multiplexed) |
Binary Protocol Buffers (protobuf) |
Strictly compiled proto schema contracts |
Ultra-Fast (Microsecond binary serialization) |
High-throughput Internal Microservices & Real-Time IoT Systems |
| SOAP (W3C Legacy) |
HTTP, SMTP, TCP |
XML Only (WSDL envelope) |
Rigid WSDL contracts with WS-Security |
Slower (Heavy XML parsing & verbose headers) |
Legacy Enterprise Banking, Defense & Healthcare Systems |
1. Network
Client Request
URL, Headers, JSON
➔
2. ASGI Engine
Uvicorn Server
Async Event Loop
➔
3. Routing
Starlette Router
Path Matching
➔
4. Parsing & Safety
Pydantic v2
Type Validation
➔
5. Execution
Path Operation
Async Logic & Depends
➔
6. Output
JSON Response
Status Code & Headers
Figure 1.2: End-to-end traversal of a request inside FastAPI. Uvicorn receives raw ASGI packets, Starlette routes to the matching endpoint, Pydantic parses and validates incoming JSON into strongly-typed models, FastAPI resolves dependency trees via Depends(), runs the asynchronous function, and serializes the return value into JSON.
🚀
Why FastAPI is the Premier Framework for Modern REST APIs
FastAPI achieves its benchmark-topping speeds and industry adoption because it directly leverages Python 3.10+ type hints. By uniting Starlette's raw ASGI throughput with Pydantic's compiled C-speed parsing, FastAPI gives developers automatic interactive OpenAPI documentation, instant request sanitization, and enterprise-grade concurrency without writing tedious boilerplate validation code.