Test 202 Akzeptiert und asynchrone Jobabfrage

Der Statuscode 202 „Akzeptiert“ wird von Clients am häufigsten falsch interpretiert, da er eine Erfolgsmeldung für einen noch nicht abgeschlossenen Vorgang darstellt. Das Protocol Lab modelliert den gesamten Ablauf: Absenden, Empfangen des Statuscodes 202 mit einer Status-URL, regelmäßiges Abfragen bis zum Abschluss des Vorgangs und anschließende Behandlung des fehlgeschlagenen Vorgangs.

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

Starten Sie einen Job, lesen Sie Location aus der Antwort 202 und fragen Sie den Status ab, statt den Abschluss vorauszusetzen.
Verwenden Sie ein sinnvolles Abfrageintervall und eine Versuchslimitierung. Vermeiden Sie eine Endlosschleife bei Jobs ohne Abschluss.
Behandeln Sie einen fehlgeschlagenen Job: Die Statusabfrage kann erfolgreich sein, obwohl die eigentliche Arbeit fehlschlug.
Prüfen Sie das Clientverhalten, wenn der Job den gesamten Timeout überschreitet.
Kombinieren Sie die Abfragen mit den Endpunkten für 503 und 504, um unzuverlässige vorgelagerte Dienste zu simulieren.

APIs, um es auszuprobieren

Protocol Lab API — Async jobs, redirects, 503/504, JSON Patch & content negotiation. (12 endpoints)
Event Streams API — SSE events, replay cursors, heartbeats & ordering. (3 endpoints)
Fun Data Bridge API — Seeded fixtures from schemas, inspired by fundata.dev. (4 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.
ETag- und If-Match-Test— Provoke a 412 Precondition Failed by writing with a stale ETag — the check that stops two clients silently overwriting each other.
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.

Einstiegsanleitung · Alle 39 Mock-REST-APIs

Zuletzt aktualisiert 16. Oktober 2026