A `POST /orders` endpoint that accepts whatever JSON keys happen to match its ORM model's column names will, sooner or later, accept a `status: "paid"` field from a client who guessed the column name existed, silently trusting the client to correctly set a value that was supposed to be entirely server-controlled. Nobody wrote a line of code that says "let clients set order status on creation" — the hole exists because nobody wrote a line of code that says the opposite either, and the ORM's convenience did exactly what convenience always does: accepted the shape that was easiest to write, not the shape that was actually safe to expose.
Request and response modelling looks like plumbing — reshape input into output — but it's actually the layer that decides what a client is trusted to say and what a client is told, and a decision that's never made deliberately still gets made, by accident, by whichever serializer or ORM feature happened to be the path of least resistance that week. The same carelessness cuts both ways: an under-specified request body invites overposting, and an under-specified response body forces every consumer to write defensive parsing code for ambiguity the API could have simply removed.
This lesson works through what genuinely belongs in a request body versus the URL, why a field explicitly set to null and a field simply omitted are two different instructions rather than one, how to shape a response envelope and represent relationships between resources, and the value-formatting discipline — dates, money — that keeps an API's payloads predictable enough for both humans and generated client code to trust.
Analogy🏏Cricket
🏏 Think of it like cricket: A team's official playing-eleven submission to the match referee before the toss has a fixed, deliberate set of fields — eleven names, each player's role, who's designated wicketkeeper, who's captain — and nothing else the team fills in gets treated as binding. If a team, filling out that same form, added a note like "result: win" in some blank space at the bottom, the match referee doesn't record that as the outcome; the field simply isn't part of what the form is for, and the referee's intake process was built to read only the specific fields the form actually defines, not whatever additional text happens to appear on the page. Now imagine an intake process built carelessly instead, auto-recording whatever fields happen to be present on a submitted sheet — including a team scribbling in a made-up "toss winner" field before the actual toss has taken place. Nobody explicitly decided teams get to pre-declare the toss result; that hole exists purely because nobody's process explicitly closed it. Just as a well-run submission process reads only the specific fields it defines and ignores everything else a team might write, a well-designed request body accepts only the fields a client is actually trusted to set and rejects or ignores the rest, including fields like `status` or `id` that belong to the server alone. Just as the referee's intake process has to be built deliberately to close that toss-result hole, request modelling has to deliberately decide what a client may say — leaving it undecided quietly hands that decision to whichever field name a client happens to try.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.