Eine REST-API in 5 Minuten testen

Ziel: von einer OpenAPI-Spezifikation ausgehen und zu einem automatisierten Test gelangen, der einen vollständigen Ablauf überprüft.

1. Die Spezifikation importieren (30 Sekunden)

Datei ▸ Importieren (Ctrl+I), dann die URL Ihrer openapi.json.

Restorm baut den vollständigen Baum auf: einen Ordner pro Tag, eine Anfrage pro Operation, typisierte Parameter, die Dokumentation sowie vorverdrahtete Authentifizierungs-Header mit ihren Variablen.

Der durch den OpenAPI-Import erzeugte Baum, einsatzbereit: ein Ordner pro Tag (pet, store, user) und eine vorausgefüllte Anfrage pro Operation, neben dem Start-Unter-Tab des Variablenordners

Falls Ihre API keine Spezifikation hat, fügen Sie einen curl-Befehl ein — siehe cURL-Befehle importieren.

2. Die Umgebung ausfüllen (1 Minute)

Öffnen Sie den vom Import erstellten Variablenordner. Die Basis-URL ist bereits vorhanden; vervollständigen Sie die Authentifizierungsvariable, die der Import für Sie vorbereitet hat.

Erstellen Sie eine zweite Umgebung, wenn Sie mehrere Ziele testen — der Umschalter in der Smartbar wechselt den gesamten Ordner auf einmal.

3. Einen ersten Aufruf senden (30 Sekunden)

Öffnen Sie eine Anfrage, klicken Sie auf Send. Die Antwort erscheint: Status, Zeit, Header, Body in einem aufklappbaren Viewer.

Falls Sie etwas vergessen haben, teilt Ihnen der aufgelöste Wert unter dem URL-Feld dies mit.

4. Das Szenario aufbauen (2 Minuten)

Rechtsklick ▸ Hinzufügen ▸ Szenario. Der Ablauf „erstellen, lesen, löschen“:

HTTP-Anfrage „POST /clients“
     └─response──► Assert (eq, 201)
              └─► Variable setzen „clientId“   ◄── Selektor body.id

HTTP-Anfrage „GET /clients/{id}“
     └─response──► Assert (eq, 200)
              └─► Schema validate (das JSON Schema des Kunden)

HTTP-Anfrage „DELETE /clients/{id}“
     └─response──► Assert (eq, 204)

Die drei Anfragen verwenden {{clientId}} in ihrer URL: Die im ersten Schritt gesetzte Run-Variable wird von den folgenden gelesen.

Verketten Sie sie, indem Sie den done-Port jeder Assertion mit dem in-Port der nächsten Anfrage verbinden — das garantiert die Reihenfolge.

5. Überprüfen (30 Sekunden)

Klicken Sie auf Play. Das Protokoll füllt sich; fügen Sie nach jedem Schritt eine Aktion Log hinzu, um nachzuverfolgen, was wichtig ist.

Verbinden Sie eine Aktion Throw mit dem Ausgang else Ihrer kritischen Assertions: Das lässt den CI-Job fehlschlagen.

6. Automatisieren (30 Sekunden)

RESTORM_TOKEN=rstk_… restorm \
  --open ./api.restorm \
  --run "Kundenablauf" \
  --headless \
  --out run.log

Exit-Code 0, wenn alles besteht, sonst 1. Siehe Headless-Ausführung und CI für die GitHub-Actions- und GitLab-CI-Beispiele.