API-Testing: Postman und curl

Nach acht Lektionen über das Designen und Absichern von APIs widmen wir uns dem Prüfen. Wer eine API entwickelt, muss sie testen können – händisch beim Programmieren, automatisiert in der CI/CD-Pipeline, integrativ mit anderen Services. Wer eine fremde API benutzt, muss sie erkunden können – „funktioniert mein Aufruf?", „was kommt zurück?", „warum klappt es nicht?".

Zwei Werkzeuge dominieren diesen Bereich: Postman (grafisches Tool mit allem Komfort) und curl (Kommandozeilen-Klassiker, in jedem Linux/Mac vorinstalliert). Diese Lektion zeigt beide in Aktion, ergänzt um HTTPie (die moderne curl-Alternative). Du lernst, REST-APIs zu testen, automatisierte Test-Skripte zu schreiben und Postman-Collections für dein Team zu pflegen.

1) Warum API-Testing wichtig ist

API-Tests sind das Sicherheitsnetz unter jeder professionellen API. Die Aufgabe geht weit über „funktioniert sie?" hinaus:

Funktionalität prüfen: tut die API, was sie soll?
Regressionen vermeiden: ändert ein neuer Commit unbeabsichtigt das Verhalten?
Edge Cases abdecken: was passiert bei ungültigen Inputs, fehlender Auth, leeren Listen?
Performance messen: wie schnell antworten die Endpunkte unter Last?
Sicherheit prüfen: greift Rate Limiting? Werden Tokens validiert? Vgl. L8.
Doku validieren: tut die API, was die OpenAPI-Spezifikation behauptet?

Eine schöne Analogie: API-Tests sind wie die TÜV-Prüfung für deinen Code. Das Auto fährt zwar auch ohne TÜV – aber niemand will damit auf die Autobahn. So ist es mit ungetesteten APIs in Produktion auch.

2) Postman – das grafische Schweizer Messer

Postman ist das beliebteste Tool für API-Arbeit. Es bietet eine grafische Oberfläche, mit der man Requests zusammenklicken, abschicken, die Antworten inspizieren kann. Dazu kommen mächtige Features: Variablen, Environments, automatisierte Tests, Collections zum Teilen im Team.

So sieht ein typischer Postman-Bildschirm aus – grob nachgebaut:

Postman-Interface (vereinfacht)

GET

https://api.example.com/users/{{userId}}

Params

Headers

Body

Auth

Tests

# Headers Authorization: Bearer {{accessToken}} Accept: application/json X-Request-ID: {{$randomUUID}}

200 OK 142 ms · 312 B

{ "id": 7, "name": "Anna Müller", "email": "anna@example.com", "role": "admin" }

Bemerke die doppelten geschweiften Klammern: {{userId}} und {{accessToken}}. Das sind Variablen, die Postman beim Senden ersetzt. $randomUUID ist eine dynamische Variable – generiert für jeden Request eine neue UUID. Die Reiter Params, Headers, Body, Auth, Tests bieten alles, was du für einen kompletten Request brauchst. Im Reiter „Tests" lassen sich automatisierte Assertions schreiben (gleich mehr dazu).

3) Environments und Variablen

Ein Killer-Feature von Postman: Environments. Du legst pro Umgebung (lokal, Staging, Produktion) ein Set von Variablen an. Mit einem Klick wechselst du zwischen ihnen – alle Requests zeigen plötzlich auf den richtigen Server.

So strukturiert man das typischerweise:

Local: baseUrl = http://localhost:3000, userId = 1, accessToken = dev_token
Staging: baseUrl = https://staging-api.example.com, userId = 100, ...
Production: baseUrl = https://api.example.com, userId = production_user, ...

In den Requests selbst nutzt du nur noch {{baseUrl}}/users/{{userId}}. Beim Senden wird ersetzt. So testest du denselben Request gegen jede Umgebung – ohne den Request umzuschreiben.

4) Collections: API-Workflows organisieren

Eine Collection ist eine geordnete Gruppe von Requests – wie ein Notizbuch für deine API. Collections werden im Team geteilt, in Git versioniert, in CI/CD ausgeführt. Eine typische Struktur:

Postman-Collection-Struktur

📁 Shop-API v2 ├── 📁 Auth │ ├── POST Login │ ├── POST Refresh Token │ └── POST Logout ├── 📁 Users │ ├── GET Liste alle User │ ├── GET Hole User by ID │ ├── POST Neuen User anlegen │ ├── PUT User ersetzen │ └── DEL User löschen ├── 📁 Products │ ├── GET Liste mit Filtern │ └── ... └── 📁 Orders └── ...

Eine gut gepflegte Collection ist Gold wert: sie dient als lebende Dokumentation der API, als Test-Suite, als Demo-Material für neue Teammitglieder. Im Idealfall exportierst du sie als JSON und versionierst sie in Git zusammen mit dem API-Code. Aus der gleichen Datei lässt sich später eine OpenAPI-Spezifikation erzeugen (oder umgekehrt).

5) Automatisierte Tests in Postman

Postman wäre nur halb so mächtig, wenn man jeden Request manuell prüfen müsste. Im Reiter „Tests" schreibst du JavaScript-Code, der nach jeder Antwort ausgeführt wird. Hier ein typisches Beispiel:

Postman-Test-Skript (Tab „Tests")

// Status-Code prüfen pm.test("Status ist 200", function() { pm.response.to.have.status(200); }); // Antwortzeit messen pm.test("Antwort unter 500ms", function() { pm.expect(pm.response.responseTime).to.be.below(500); }); // JSON-Struktur validieren pm.test("Antwort hat User-Felder", function() { const json = pm.response.json(); pm.expect(json).to.have.property("id"); pm.expect(json).to.have.property("name"); pm.expect(json.email).to.match(/@/); }); // Token aus Login-Response extrahieren und speichern const json = pm.response.json(); pm.environment.set("accessToken", json.access_token);

Beachte den letzten Block: er extrahiert das Access-Token aus der Login-Response und speichert es als Environment-Variable. Folgende Requests in der Collection können dann {{accessToken}} nutzen – ohne dass du es manuell kopieren musst. So baust du Test-Ketten: Login → Token speichern → mit Token andere Endpunkte aufrufen. Die Tests laufen auch in der Kommandozeile mit Newman (Postman's CLI-Runner) – ideal für CI/CD-Pipelines.

6) curl – die Kommandozeile als API-Werkzeug

curl ist auf jedem Linux- und macOS-System vorinstalliert, unter Windows seit Windows 10 ebenfalls. Es ist das universelle HTTP-Werkzeug für die Kommandozeile: ohne Installation verfügbar, mit Skripten kombinierbar, in jeder Server-Umgebung nutzbar.

Die wichtigste Eigenschaft: was du mit Postman per GUI machst, machst du mit curl in einem Einzeiler. Hier dieselbe Anfrage in drei Werkzeugen – die Funktion identisch, die Notation unterschiedlich:

Dieselbe POST-Anfrage in drei Tools

# Einen User anlegen mit curl curl -X POST https://api.example.com/users \ -H "Authorization: Bearer eyJhbGc..." \ -H "Content-Type: application/json" \ -d '{ "name": "Anna", "email": "anna@x.de" }'

curl ist die Lingua franca: jede Doku zeigt curl-Beispiele, jeder Tutorial macht es vor, jeder Server-Admin kann's. Praktisch: in Postman gibt es einen Knopf „Code → cURL" – jeder Postman-Request lässt sich als curl-Befehl exportieren und umgekehrt importieren. Für CI/CD und Skripte ist curl unschlagbar – Postman fühlt sich für Exploration besser an. HTTPie ist eine moderne Alternative: lesbarere Syntax, schönere Ausgabe, aber muss installiert werden (pip install httpie).

7) Die wichtigsten curl-Optionen

curl hat über 200 Optionen, aber 10 davon decken 95 % der Praxis ab:

curl-Cheatsheet für API-Tests

-X <METHOD>

HTTP-Methode festlegen. -X POST, -X DELETE. Bei GET implizit.

-H <Header>

Header setzen. Mehrere -H möglich. -H "Content-Type: application/json"

-d <Body>

Request-Body übergeben. -d '{ "x": 1 }'. Auch -d @file.json aus Datei.

-i

Antwort-Header zusätzlich anzeigen. Praktisch zum Debuggen von Status/Headers.

-v

Verbose: alles anzeigen – Request und Response in voller Pracht. Klassiker beim Fehlersuchen.

-o <file>

Antwort in Datei schreiben statt stdout. Praktisch für Downloads.

-s

Silent: keine Progress-Anzeige. Nützlich in Skripten.

-L

Redirects automatisch folgen (3xx-Antworten). Sonst zeigt curl nur „Moved" an.

--user user:pass

Basic Auth einfach setzen. Hängt automatisch korrekten Header an.

--data-urlencode

URL-encoded Daten senden – z.B. für form-data, wenn der Body Sonderzeichen enthält.

In der Praxis kombinierst du diese:

curl -v -X POST -H "Authorization: Bearer ..." -H "Content-Type: application/json" -d '{...}' https://api.example.com/users

. Schreckt erst ab, wird aber schnell Routine. Tipp: wenn du beim Tippen Tippfehler hast, ist -v dein bester Freund – zeigt jedes Detail.

8) Wann Postman, wann curl?

Beide Tools haben ihre Stärken. Eine pragmatische Faustregel:

Postman: beim Erkunden einer neuen API, beim Aufbau einer Collection fürs Team, beim Schreiben automatisierter Tests mit JS, in Pair-Programming-Sessions. Großer Vorteil: Variablen-Management.
curl: in CI/CD-Pipelines, in Shell-Skripten, beim Debuggen auf einem Produktiv-Server (wo Postman nicht installiert ist), in Dokumentations-Beispielen (universell verständlich).
HTTPie: als persönlicher Daily-Driver, wenn du curl-Syntax umständlich findest. Schöner formatierte Output.
Newman: wenn du Postman-Collections in der Pipeline automatisch laufen lassen willst.

9) API-Test-Hierarchie

API-Tests gliedern sich in mehrere Ebenen, von leicht zu schwer:

Test-Ebenen für APIs

Smoke-Tests

Basis: läuft die API überhaupt? GET /health → 200. Nach jedem Deploy.

Funktionstests

Jeder Endpunkt einzeln: richtige Status-Codes, richtige Antwort-Struktur, plausible Daten.

Integrationstests

Endpunkt-Ketten: Login → User anlegen → User suchen → User löschen. Real-World-Flows.

Negativ-Tests

Was passiert bei ungültigen Inputs? Fehlendem Token? Verbotenen Aktionen? Sollte 400/401/403 sein, nicht 500.

Last-Tests

Wie schnell? Wie viele parallel? Tools wie k6, JMeter, Artillery, Locust.

Contract-Tests

Hält die API den vertraglich vereinbarten Output ein (z.B. die OpenAPI-Spec)? Tool: schemathesis, dredd.

In der Praxis fängt jedes Team mit Smoke- und Funktionstests an. Integrationstests kommen hinzu, sobald die API komplexer wird. Last- und Contract-Tests sind Profi-Themen. Wichtig: API-Tests gehören in deine CI/CD-Pipeline – bei jedem Commit laufen sie automatisch. Vgl. K50 L7 zu Microservices.

10) Was du in Tests typischerweise prüfst

Welche Assertions sind die häufigsten? Eine Liste, die du als Vorlage für eigene Test-Suites nehmen kannst:

Status-Code: 200 bei Erfolg, 201 bei Create, 4xx bei Client-Fehlern – aus L2.
Antwortzeit: unter dem SLA-Wert (z.B. < 200 ms).
Content-Type-Header: application/json wie erwartet.
JSON-Struktur: alle Pflichtfelder vorhanden, richtige Datentypen.
Werte plausibel: User-ID ist eine positive Zahl, E-Mail enthält @, Datum im richtigen Format.
Auth-Header funktionieren: ohne Token → 401, falsches Token → 401, gültiges Token → 200.
Berechtigung respektiert: User darf nicht andere User löschen → 403.
Pagination konsistent: page=1&size=20 liefert 20 Einträge, Meta enthält total und has_next.
Rate-Limit-Header gesetzt: X-RateLimit-Remaining wird mit jedem Request kleiner. Aus L8.

11) Best Practices für saubere Test-Workflows

Test-Hygiene

Collection in Git

Postman-Collection als JSON exportieren, mit dem API-Code versionieren. Wer ändert die API, ändert die Tests mit.

Echte Test-Daten

Eigene Test-User, eigene Test-Daten, eigenes Schema. Niemals gegen Produktion testen.

Idempotente Tests

Tests müssen mehrfach laufen können. Anlegen → testen → wieder löschen, oder Test-DB nach jedem Lauf zurücksetzen.

Newman in CI/CD

Postman-Collection mit Newman in der Pipeline ausführen. Failed Tests = roter Build = kein Deploy.

Keine Secrets in Git

Tokens, Passwörter NIE in der Collection committen. Aus Environment-Variablen ziehen, Secret-Stores nutzen.

Mock-Server für offline

Postman kann Mock-Server hosten, die deine API simulieren. Frontend-Entwicklung parallel zu Backend möglich.

12) Klausurrelevante Punkte

Was ist Postman / curl? – Tools zum Senden und Inspizieren von HTTP-Requests.
Was ist eine Collection? – Gruppierung von Requests, geteilt und versioniert.
Environments – Variablen-Sets pro Umgebung (lokal/staging/prod).
Newman – Postman's CLI für CI/CD.
Wichtigste curl-Optionen: -X (Methode), -H (Header), -d (Body), -v (verbose).
Test-Ebenen: Smoke, Funktionstest, Integration, Negativ, Last.

Zusammenfassung

Postman ist das beliebteste grafische API-Tool: Request bauen, abschicken, Antwort inspizieren, Tests in JavaScript schreiben. Killer-Features: Environments (Variablen-Sets pro Umgebung, Switch per Klick) und Collections (geordnete Request-Gruppen, in Git versionierbar als lebende API-Doku). Variablen-Syntax {{baseUrl}}. Tokens aus Login-Response automatisch in Environment speichern für Folge-Requests. Newman ist Postmans CLI-Runner – ideal für CI/CD-Pipelines. curl ist der Kommandozeilen-Klassiker, überall vorinstalliert. Wichtigste Optionen: -X (Methode), -H (Header), -d (Body), -v (verbose zum Debuggen). HTTPie als moderne Alternative mit lesbarerer Syntax. Test-Hierarchie: Smoke-Tests (lebt die API?), Funktionstests (jeder Endpunkt), Integrationstests (End-zu-End-Flows), Negativ-Tests (400/401/403-Fälle), Last-Tests (k6, JMeter), Contract-Tests (gegen OpenAPI). Typische Assertions: Statuscode, Antwortzeit, JSON-Struktur, Auth-Verhalten, Rate-Limit-Header (aus L8). Auswahl-Faustregel: Postman zum Erkunden im Team, curl in Skripten und Doku, Newman in der Pipeline. Klausur-Fokus: Postman/curl als Test-Tools, Collection/Environment definieren, Newman für CI/CD, typische curl-Optionen. Nächste Lektion: IHK-Aufgaben API.