Eine simulierte API beantwortet Anfragen so, wie es ein echter Dienst tun würde – mit denselben URLs, Statuscodes und Antwortstrukturen –, ohne dabei auf die Systemkomponenten zurückzugreifen, von denen der echte Dienst abhängt. Sie dient dazu, einen Client zu entwickeln, zu demonstrieren oder zu testen, bevor der echte Dienst verfügbar ist oder wenn der Aufruf des echten Dienstes langsam, teuer, durch eine Ratenbegrenzung eingeschränkt oder gar schädlich wäre.
Mocks lassen sich in drei Hauptformen einteilen. Ein statischer Mock gibt immer dieselbe vordefinierte Nutzlast zurück. Mit einem konfigurierbaren Mock können Sie für jeden Endpunkt festlegen, was zurückgegeben werden soll. Ein simulierter Mock – wie dieser Playground – speichert tatsächlich einen Zustand: Ein POST-Request erstellt etwas, das ein späterer GET-Request finden kann, ein DELETE-Request löscht es, und Einschränkungen wie Lagerbestände, Lizenzverfügbarkeit und Versionskonflikte werden durchgesetzt, anstatt nur beschrieben zu werden.
Die gängige Annahme ist, dass ein Mock keine Fehlerbehandlung üben kann, da ein Mock immer erfolgreich ist. Das ist eine Eigenschaft der meisten Mocks, nicht des Mockings an sich. Gerade die Fehlerpfade – 409, 412, 429, 503 – sind am schwierigsten bei einem realen Dienst zu provozieren und daher am wertvollsten für Übungen. Aus diesem Grund eignet sich eine API, die immer nur 200 zurückgibt, schlecht als Übungsziel.
Jede API hier funktioniert in beide Richtungen: entweder komplett im Browser ohne Netzwerkverbindung oder über HTTPS gegen ein Live-Backend. Die Browser-Engine verwendet denselben Code, daher stimmen die Antworten überein.
Diese Seite auf Englisch lesen
Alle Glossarbegriffe · Testtechniken · Alle 39 Mock-REST-APIs
Zuletzt aktualisiert