CHAPTER 08 / 13 · READ → DECIDE → BUILD
Make every side effect deliberate.
Validate requests, enforce identity, and handle retries.
Build a boundary, not just a handler
The claim endpoint receives untrusted input. Validate the task identifier, derive the user identity from the authenticated session, check permission, and perform the atomic claim operation. Return a stable response for success, invalid input, signed-out access, missing task, and conflict. Do not send internal stack traces to users. Logs should help diagnosis without collecting tokens or private payloads.
A timeout does not tell you whether the write happened
Imagine the database commits a claim and the network drops before the browser receives confirmation. A retry must not create a second side effect or mislead the user. Define what happens when the same user requests the same claim again. For more complex operations, use an idempotency key with a clear scope and payload policy. Always distinguish a repeated request from a genuinely different request that happens to arrive nearby.
Keep external work recoverable
The learning board does not need email to prove the claim flow. If you add a notification later, decide what happens when the claim succeeds but email fails. You may need a durable job or outbox pattern rather than treating both as one fragile request. Bound timeouts and retries. A dependency that fails permanently should lead to a visible, diagnosable state rather than endless background attempts.
SEE THE DIFFERENCE
A small example. A better decision.
Any failed response means the claim did not happen. Create another claim on retry.
Check the operation's idempotent result. If the same volunteer already owns the claim, return the documented repeat-request response without a new side effect.
Network uncertainty and operation failure are different situations. The contract should account for both.
Your build steps
- Implement the endpoint against your contract and data rule.
- Exercise it directly with valid, invalid, and unauthorized synthetic requests.
- Repeat a request and inspect the stored result.
- Record how logs and user messages explain a conflict or failed dependency.
FROM THE PROMPT LIBRARY
A useful brief for this step.
Implement a validated API endpoint ↗Keeps malformed or unauthorized requests from reaching business logic.Choose the correct transaction boundary ↗Prevents partial writes that leave the product inconsistent.Verify and process a webhook ↗Prevents forged or repeated provider events from causing unwanted actions.All backend & integrations promptsMAKE THE CALL
Think like the reviewer.
BUILD YOUR WORKBOOK
A verified claim endpoint
Use the lesson and your project evidence. Your workbook saves privately; keep credentials and private records out. The checks below assess completion of the exercise, not the correctness of an external app.
Before moving on
Loading your workbook…