Topic 6.6
REST
In one line
The dominant API style: resources + verbs + status codes + statelessness.
Think of it like this
Ordering food using a menu with fixed item numbers. Each URL is like a menu item ('/users/5' = user number 5), and you always use the same standard actions (GET to view, POST to order, DELETE to cancel) on any item.
Key ideas
- 01
REST = resources identified by URLs, manipulated with HTTP verbs, stateless per request.
- 02
Resource shapes: /users/{id}/orders — nested nouns, verbs as POST/PUT/PATCH.
- 03
Stateless: every request carries what the server needs (token, ids) — enables horizontal scaling trivially.
- 04
Versioning: /v1/users — because consumers never upgrade in lockstep.
- 05
Pagination, filtering, sorting as query params: ?limit=50&cursor=...&sort=-createdAt.
- 06
HATEOAS is mostly theoretical; interviews care about clean URIs, status codes, and idempotency.
Java / Spring map
- →
Spring MVC: @RestController, ResponseEntity, @RequestParam pagination, DTO records.
Explain without notes
What does 'stateless' make easy at scale, and what does it push into the client?
Practice
Design the REST surface for Splitwise: expenses, groups, settle — with status codes per flow.
Trade-offs
- ↔
REST's URL freedom drifts into inconsistency; gRPC contracts prevent that at the cost of HTTP semantics.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can design a REST API and justify each verb/status choice.