Testing optimistic concurrency with ETag and If-Match

Lost updates are the quietest bug in any CRUD application: two clients read the same record, both write, and the second silently discards the first one's work. Optimistic concurrency turns that into a 412 you can handle. Most of the catalog supports it, so you can rehearse both the happy path and the conflict.

How to practise it

1. GET a resource and keep its ETag, then PUT it back with If-Match and watch it succeed.
2. Have a second request modify the resource, then retry the first PUT with the now-stale ETag and collect the 412.
3. Write without an If-Match header at all and notice that nothing stops you — which is the bug this whole mechanism exists to prevent.
4. Combine with a conditional GET: send If-None-Match and confirm the 304 when nothing has changed.
5. Try the Retro Quest save-conflict endpoints, where the same idea is modelled as save-game versions.

APIs to try it on

• Football API — Teams, squads, standings & simulated matches. (7 endpoints)
• Harry Potter API — Houses, students & spells from a magic school. (10 endpoints)
• Game of Thrones API — Houses, nobles & dragons of Westeros. (12 endpoints)
• Retro Quest API — Pixel heroes, quests, loot & save-game conflicts. (5 endpoints)

Status codes involved

• 304 Not Modified
• 412 Precondition Failed

Other techniques

• Pagination testing — Practise page-number and cursor pagination, and the edge cases that break clients: the last partial page, an out-of-range page, and a total count that disagrees with what you collected.
• Rate limit testing — Trigger a real 429 with Retry-After and X-RateLimit headers, and verify your client backs off instead of retrying straight into the limit.
• Idempotency key testing — Send the same write twice with an Idempotency-Key and confirm the operation happens once — the mechanism that stops a network retry becoming a duplicate charge.
• Webhook signature testing — Register a callback, trigger a delivery, verify its HMAC signature, and confirm a tampered payload is rejected.
• OAuth and JWT testing — Run real client-credentials, authorization-code and device-code flows, then test what your client does when the token expires mid-session.
• Negative testing — Provoke 400, 401, 403, 404, 409, 418, 422, 429, 500 and 503 deliberately, and check your client handles each one differently.
• Async job testing — Start a long-running job, follow the 202 and its Location header, and poll to completion — including the failure and timeout paths.

Getting started guide · All 37 mock REST APIs