APIs & service design
P38.services.01 · Audience: guest, it-ml, language-pro · Prerequisites: Layered & hexagonal architecture
A service is a boundary other code calls across. A web framework is mostly a router in front of your handlers — so if you test the handlers directly (request in, response out), you exercise the whole contract with no socket. This module has you build an in-process API and get its two hardest details right: idempotency and versioning.
ⓘ Concept: Request in, response out
{method, path, body} maps to a response {status, body}. Status codes carry meaning — 2xx success, 4xx the caller's fault, 5xx yours. Validate at the edge so the core never sees a malformed body. Real serving stays prose (see P13 operations).Why it matters — Testing a handler as a plain function — dict in, dict out — exercises the real contract with no server, which is how you unit-test an API's behaviour fast.
Ask the mentor about this module
Ask a question about this content. The mentor explains and grounds its answer in what you are studying; asking is recorded as a learning signal, not a grade.
🎓 Practice ladder
2 graded rungs · ~26 minBuild an in-process API with idempotency and versioning, then design an API in an interview-style prompt.
Rung 1 — an in-process API
Loading exercise…
Rung 2 — API & service design (interview)
Loading exercise…
You can design a service. Next, the capstone ties the whole pillar together — architected, idempotent, and resilient.
Where next?
Later in APIs, Services & the Capstone
This module unlocks