8. HTTP status, payload and postconditions

An HTTP response supplies several kinds of evidence: status, headers, body and observable effects. The useful combination depends on the contract. A catalogue read needs the correct records, while a save command also needs a stored postcondition and an account boundary.

Fetch can resolve a response for an HTTP error status. Transport rejection and a response carrying 400 or 500 are different outcomes. Record which layer failed before deciding whether retrying is appropriate.

The worked case checks that a public catalogue query returns 200 and exactly r1 for UA plus qa. A status-only assertion would miss an overbroad result. The local fixture gives a complete independent expected id list.

For a 204 save response, do not require a JSON body. Read the saved list afterward instead. Conversely, a validation failure should not modify saved state merely because the client receives a documented error message.

The weak case accepts every 200 response without inspecting records. A server returning the entire catalogue would pass it. Another common mistake is parsing JSON unconditionally for a response whose contract intentionally has no body.

Do not retry every failed write blindly. Consider method semantics, idempotency and whether the server may have accepted the action before the connection failed. A timeout does not prove that nothing happened.

Write three API cases: a valid UA query, an invalid zero limit, and an anonymous saved-list read. State expected status and any meaningful body or no-change evidence. Begin with the public query and its complete id list.

Run only the local companion API. The exercise does not authorize requests against real accounts or third-party feeds. Optional extension: save one synthetic role as the owner and verify it through a separate read.

Step 1: Specify the public query’s expected ids. Step 2: Add the invalid-limit and anonymous-private-read cases.

The solution expects 200 with r1, 400 for the invalid limit and 401 for the private anonymous read. The API verifier sends these requests to the loopback lab and inspects the body for the successful catalogue case.

The statuses are the lab’s documented contract rather than universal rules for every endpoint. Keep payload and side-effect expectations attached to the relevant operation, and avoid treating an error response’s arrival as proof that all failure behavior is correct.

In interviews, explain why status, payload and postconditions can expose different defects. Describe a 204 case without a body and a 200 case with incorrect data. Keep transport failures distinct from server-generated error responses.

Next, examine payload schemas and semantic contracts. Valid JSON and a successful status are still insufficient when required fields or business values are wrong.

Optional stretch — after the core task works: Verify an idempotent save through a separate read.

Computer practice: download the companion lab at https://applydjinn.com/typorithm/qa-lab-20261105.zip. Read its README, install the pinned tools and run the accepted examples before attempting a starter. The mobile reader preserves your reading and self-check progress; the local lab runs browser tests separately.