In this chapter
We'll follow one REST API request through its whole life — from the client, across the network, through the server's layers of checks, to the database and back as a JSON response with a status code — explained as a parcel going through a sorting office.
The Problem in Real Life
To understand Friday, John asks Anna to explain first how a normal API request works — the kind the mobile app sends a thousand times a minute. "You know REST from Act 12. Now follow one request through every step inside our server. The bug lives in one of those steps."
Anna picks a simple one: the mobile app creating an order — POST /v1/orders.
So a request isn't one step. It's a little journey.
Anna
"The App Calls the Server" vs. Every Step in Between
Many steps, many failures
A request passes through the network, a load balancer and several layers of code. Each can fail.
Checks before work
Who's asking, are they allowed, is the input valid — all before touching the database.
A clear answer
The response must say clearly whether it worked, what happened and what to do next.
REST APIs and the Request/Response Lifecycle
The sorting office analogy: a parcel is posted. It travels to a sorting office, where it passes through stations: the address is checked, the stamp is checked, the size is checked, it's scanned, it's sent to the right van, and finally it's delivered — and the sender gets a delivery receipt. If any station rejects it, the parcel comes back with a note saying why. An API request goes through the same kind of stations.
- REST, quickly (Act 12): a REST API organises everything as resources with addresses (
/v1/orders,/v1/orders/1042) and uses HTTP methods as verbs: GET reads, POST creates, PUT/PATCH updates, DELETE removes. Data travels as JSON. Each request carries everything needed to handle it (stateless). - 1. The client builds the request: method (
POST), URL (https://api.blueticket.example/v1/orders), headers (Authorization,Content-Type: application/json) and a body — the JSON with the seats and the event. - 2. The network (Acts 11, 12, 19): DNS finds the address, TLS encrypts the connection, the load balancer picks a healthy server.
- 3. Routing — which desk handles it: the server's router matches
POST /v1/ordersto the right piece of code (a handler, or controller). - 4. Middleware — the checking stations: before the handler runs, the request passes through middleware: small layers that each do one check. Is there a valid token (authentication, Act 22)? Too many requests from this client (rate limit)? Is the JSON well-formed? Is it logged with a request ID (Act 17) so it can be traced? Any station can stop the request with an error.
- 5. Validation and authorization: the handler checks the body — are the seat IDs real, is the quantity 1–6? — and whether this user may do this (Act 22).
- 6. Business logic and data: the actual work: hold the seats in a transaction (Act 13), calculate the price, create the order in the database, maybe put a message on a queue (Act 14).
- 7. The response — the delivery receipt: the server sends back a status code (201 Created), headers, and a JSON body describing the result: the new order's ID, total and status. The client reads the status code first, then the body.
| Step | Sorting-office version | If it fails |
|---|---|---|
| Routing | Send to the right desk | 404 Not Found |
| Authentication | Is the stamp genuine? | 401 Unauthorized |
| Rate limit | Too many parcels from one sender | 429 Too Many Requests |
| Validation | Is the address complete? | 400 / 422 |
| Authorization | May this sender use this service? | 403 Forbidden |
| Business logic | The actual delivery | 409 Conflict (seat taken), 500 (bug) |
The life of POST /v1/orders
Client (mobile app)
POST /v1/orders + token + JSON body
Network + load balancer
DNS, TLS, healthy server
Router
→ createOrder handler
Middleware
auth · rate limit · request ID
Handler
validate · authorize · work
Database
hold seats, create order
Response: 201 Created + JSON
order ID, total, status
POST /v1/orders HTTP/1.1Host: api.blueticket.exampleAuthorization: Bearer eyJhbGciOi...Content-Type: application/json{ "eventId": "evt_311", "seatIds": ["C14", "C15"] }--- response ---HTTP/1.1 201 CreatedContent-Type: application/jsonX-Request-Id: req_9f2a71{ "orderId": "ord_1042", "status": "awaiting_payment", "total": 178.00, "holdExpiresAt": "2026-11-20T19:57:00Z" }
Where Friday's request was different: the order request above comes from a client to BlueTicket. The payment provider's callback on Friday came from the provider to BlueTicket's server — but it went through exactly the same stations. Anna checks the logs for one of the fourteen: the callback arrived, passed authentication, reached the handler... and the provider closed the connection after 10 seconds, while the handler was still busy. The request didn't fail at a station. It was simply too slow to answer.
Key Takeaway
A REST request is a journey through stations, like a parcel in a sorting office: the client builds it (method, URL, headers, JSON body); the network delivers it (DNS, TLS, load balancer); the router finds the handler; middleware checks authentication, rate limits and format and adds a request ID; the handler validates input and permissions, does the work with the database; and the response returns a status code and a JSON body. A failure — or slowness — at any step affects the whole request.
Why This Matters
Knowing every step a request passes through tells you where to look when something goes wrong — routing, auth, validation, the database or simply time. It's also how backend frameworks are organised (routers, middleware, handlers), so it makes any new framework easier to learn.
Status codes like 401, 409 and 429 decide what the caller should do next. And on Friday, the payment provider's own rules about errors and time limits decided that fourteen fans would get no ticket.
