fundamentals
REST Principles
Design HTTP APIs around resources and uniform verbs — predictable, cacheable, and easy to consume.
REST is an architectural style for designing networked APIs around resources — nouns like /orders and /orders/42 — manipulated through a small, uniform set of HTTP verbs, rather than around actions. The alternative, RPC-style endpoints like /getOrders, /createOrder, and /updateOrderStatus, multiplies without bound and ignores the semantics HTTP already gives you for free. REST's appeal is predictability: once a consumer learns the conventions, every endpoint in the API behaves the way they expect.
A filing cabinet: each folder (resource) has a known location (URL). You open, file, replace, or remove — verbs are constant, the contents vary.
Key Concepts
1
The core ideas are a uniform interface and statelessness. You model the domain as resources, each addressable by a URL, and act on them with standard methods whose meanings are fixed: GET reads, POST creates, PUT replaces, PATCH partially updates, and DELETE removes. These verbs carry properties clients and infrastructure rely on — GET is safe (no side effects) and cacheable, and GET, PUT, and DELETE are idempotent (repeating them is harmless). Statelessness means each request carries everything needed to process it, with no server-side session between calls, which is what lets you scale horizontally by adding interchangeable servers behind a load balancer. Done well, this makes the API leverage HTTP caching, conditional requests, and status codes instead of reinventing them.
GETPOSTPUTPATCHDELETE
2
The level of detail interviews reward is knowing the verb semantics cold — which are safe, which are idempotent, and why that matters for retries and caching — and recognising the Richardson Maturity Model that grades how "RESTful" an API is, from RPC-over-HTTP up through proper resources, verbs, and hypermedia (HATEOAS). In practice most production APIs stop short of full hypermedia, and a balanced answer acknowledges that pragmatic resource-and-verb design captures the bulk of REST's value without dogmatism.
3
What the interviewer is probing.
What the interviewer is probing.
4
1. "What makes an API RESTful?" *Probing:* the fundamentals. *Stalls:* "It uses HTTP." *Moves
up:* resources identified by URIs, a uniform interface over HTTP verbs, statelessness, and
representations the client negotiates.
1. "What makes an API RESTful?"
5
2. "What does stateless actually require?" *Probing:* the precision. *Stalls:* "No sessions."
*Moves up:* each request carries everything needed to serve it, so any instance can handle it —
which is what makes scaling horizontal.
2. "What does stateless actually require?"
6
3. "What is HATEOAS and is it used?" *Probing:* honesty. *Stalls:* "It is essential." *Moves
up:* hypermedia links driving state transitions — genuinely rare in practice, and worth saying so
rather than pretending.
3. "What is HATEOAS and is it used?"
7
4. "When is REST the wrong style?" *Probing:* judgement. *Stalls:* "Never." *Moves up:*
high-volume internal service-to-service calls where gRPC is more efficient, or highly variable
client data needs where GraphQL fits.
4. "When is REST the wrong style?"