Testen der optimistischen Parallelität mit ETag und If-Match

Verlorene Aktualisierungen sind der unauffälligste Fehler in jeder CRUD-Anwendung: Zwei Clients lesen denselben Datensatz, beide schreiben ihn, und der zweite verwirft stillschweigend die Änderungen des ersten. Optimistische Parallelverarbeitung wandelt dies in einen behandelbaren 412-Fehler um. Der Großteil des Katalogs unterstützt dies, sodass Sie sowohl den Normalfall als auch den Konfliktfall simulieren können.

Echte Endpunkte aus dem Katalog – jede der oben genannten Anfragen wird bedient, und jeder angezeigte Statuscode ist ein Statuscode, den dieser Endpunkt tatsächlich zurückgibt.

Wie man es übt

Lesen Sie eine Ressource mit GET und speichern Sie ihren ETag. Schreiben Sie mit PUT und If-Match und prüfen Sie den Erfolg.
Ändern Sie die Ressource mit einer zweiten Anfrage. Wiederholen Sie den ersten PUT mit dem veralteten ETag und erwarten Sie 412.
Versuchen Sie einen Schreibzugriff ohne If-Match. Falls der Endpunkt ihn zulässt, untersuchen Sie das Risiko überschriebener Änderungen.
Senden Sie ein bedingtes GET mit If-None-Match und erwarten Sie 304, wenn sich nichts geändert hat.
Üben Sie dasselbe Prinzip mit Spielstandversionen an den Save-Konflikt-Endpunkten von Retro Quest.

APIs, um es auszuprobieren

Fußball-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)

Betroffene Statuscodes

Andere Techniken

API-Paginierung testen — 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.
API-Ratenbegrenzung testen — Trigger a real 429 with Retry-After and X-RateLimit headers, and verify your client backs off instead of retrying straight into the limit.
Idempotenz-Schlüsseltest— 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-Signaturprüfung — Register a callback, trigger a delivery, verify its HMAC signature, and confirm a tampered payload is rejected.
OAuth- und JWT-Tests — Run real client-credentials, authorization-code and device-code flows, then test what your client does when the token expires mid-session.
Negativer Test — Provoke 400, 401, 403, 404, 409, 418, 422, 429, 500 and 503 deliberately, and check your client handles each one differently.
Asynchrone Jobtests— Start a long-running job, follow the 202 and its Location header, and poll to completion — including the failure and timeout paths.

Einstiegsanleitung · Alle 39 Mock-REST-APIs

Zuletzt aktualisiert 16. Oktober 2026