ID speichern und Verkettungen aufbauen

1. Chained requests: vom „Kopieren und Einfügen“ zum Szenario

Wenn Sie jemals manuell die id aus einer Suchergebnisantwort kopiert, sie dann in die URL des „Details“-Requests eingefügt und anschließend versehentlich die falsche id kopiert haben – herzlichen Glückwunsch: Sie wissen bereits, warum Chained Requests überhaupt erfunden wurden. Ein solcher manueller Prozess ist fehleranfällig, langsam und verdirbt ständig die Laune, wie eine eingefrorene IDE beim Speichern einer Datei (wir alle waren schon dort).

Chained Request bedeutet, dass Postman Ihnen hilft, eine „Datenstaffette“ durchzuführen: Der erste Request erhält eine Antwort, ein kleines Skript extrahiert den benötigten Wert (normalerweise eine ID), speichert ihn in der aktiven Umgebung, und der zweite Request übernimmt ihn über {{variable}}. Am Ende haben Sie nicht nur eine „Sammlung einzelner Requests“, sondern ein reproduzierbares Szenario. Und das bereitet Sie direkt auf die zukünftige Client-Phase des Projekts ReadLater Starter vor, wo der gleiche Ablauf vorkommt: catalog search → catalog details.

Wo findet man die id im JSON

Bevor man auch nur eine Zeile Skript schreibt, ist es wichtig, einen Schritt zu machen, der vielen langweilig erscheint, aber später Stunden spart: die JSON-Struktur genau anzuschauen und zu verstehen, wo genau die ID liegt. Postman ist hier nicht magisch – es rät nicht, was Sie gemeint haben. Wenn Sie den Pfad zum Feld nicht selbst kennen, „kennt“ ihn das Skript auch nicht und speichert brav undefined, und dann schauen Sie auf eine URL wie /books/ und denken, der Server sei „kaputt“.

Stellen wir uns eine vereinfachte Suchergebnisantwort vor (dies bezieht sich nicht auf einen bestimmten Anbieter, sondern auf eine typische Struktur):

{
  "items": [
    { "id": "BK-101", "title": "Clean Code" },
    { "id": "BK-102", "title": "Clean Architecture" }
  ],
  "count": 2
}

Hier interessiert uns nicht das gesamte Buchobjekt, nicht der title (der könnte sich wiederholen) und nicht einmal count (nützlich, aber nicht für Details). Uns interessiert der Pfad items[0].id, also die „id des ersten Elements der Liste“. In einer echten API kann das Feld key, externalId, bookId heißen oder tiefer liegen (z.B. items[0].book.id). Daher lautet das erste Prinzip von Chained Requests einfach: Zuerst das Feld mit den Augen finden, dann automatisieren.

Eine nützliche Angewohnheit: Den Pfad zum Feld gedanklich in Worte fassen. Zum Beispiel: „Im Wurzelobjekt gibt es ein Array items, darin das erste Element, dessen Feld id“. Wenn Sie JSON so lesen können, werden Chained Requests zur Mechanik, nicht zur Zauberei.

Der Reiter Tests: Platz für das Skript

Wenn Sie den Reiter Tests sehen, denken Sie vielleicht: „Na, das ist wohl für irgendwelche automatisierten Tests, aber wir wollen ja nur die Antworten ansehen“. Tatsächlich ist Tests in Postman einfach der Ort, an dem Sie einen kleinen JavaScript-Code ausführen können, nachdem die Antwort bereits eingetroffen ist. Und das ist der ideale Moment, um Daten aus der Antwort zu extrahieren und in einer Umgebungsvariable zu speichern.

Die Logik ist einfach. Vor dem Request wissen Sie nicht, welche id zurückkommt. Nach dem Request wissen Sie es, weil sie im Response Body steht. Also gehen wir so vor: Senden von Search → JSON erhalten → im Tests-Skript JSON lesen → Skript speichert bookId → danach verwendet Details {{bookId}}.

Das Objekt pm ist die „Postman API“ innerhalb des Skripts. Es gibt Ihnen Zugriff auf die Antwort (pm.response), auf die Umgebung (pm.environment), auf die Logs (console.log) und auf einfache Prüfungen. Sie müssen kein JavaScript-Entwickler werden. Wir verwenden genau zwei bis drei Funktionen, als ob wir einen kleinen Schraubenzieher in die Hand nehmen, statt eine Schraubenzieherfabrik zu bauen.

2. Minimales Skript in Tests

Jetzt kommt der Schlüsselmoment der Lektion, aber er ist viel einfacher, als es aussieht. Wir müssen zwei Operationen durchführen: den Body der Antwort in ein Objekt umwandeln und daraus einen Wert in der Umgebung speichern. Dafür hat Postman zwei fast selbsterklärende Werkzeuge: pm.response.json() und pm.environment.set().

Beginnen wir mit dem „Grundgerüst“ der Logik. Im Reiter Tests Ihres Suchrequests schreiben wir:

// Parse die JSON-Antwort (body) in ein Objekt, mit dem man wie mit einem normalen JS-Objekt arbeiten kann
const body = pm.response.json();

// Prüfen, ob das Feld items existiert und ob es mindestens ein Element enthält
if (body.items && body.items.length > 0) {
  // Die ID des ersten Elements der Ergebnisse nehmen (Pfad anhand des tatsächlichen JSON Ihrer API prüfen)
  const firstBookId = body.items[0].id;

  // Wert in der aktiven Umgebung speichern, damit der nächste Request {{bookId}} verwenden kann
  pm.environment.set("bookId", firstBookId);

  // Log in der Postman Console hilft, schnell zu sehen, was genau gespeichert wurde
  console.log("Gespeicherte bookId =", firstBookId); // Gespeicherte bookId = BK-101
}

Die Bedeutung der Zeilen ist buchstäblich so.

pm.response.json() nimmt den Text des Body und parst ihn als JSON. Wenn die Antwort nicht JSON ist oder JSON defekt ist, kann Postman es nicht parsen – und das ist ein nützliches Signal: entweder der Request geht falsch, der Server hat eine HTML-Fehlerseite zurückgegeben oder der Content-Type stimmt nicht.

Dann führen wir eine Prüfung durch, ob items überhaupt existiert und nicht leer ist. Und nur dann speichern wir bookId. Beachten Sie: Wir speichern ein bestimmtes Feld, nicht die gesamte Antwort. Bei Chained Requests geht es nicht darum, „alles zu merken“, sondern darum, das minimal benötigte Datenstück sauber in den nächsten Schritt zu übertragen.

Und ein kleiner Alltagstipp: console.log kann in der Postman Console angesehen werden. Das ist wie „Logging“ für Postman-Szenarien. Es hilft sehr, wenn Sie den Pfad zum Feld debuggen oder verstehen wollen, warum eine Variable nicht gespeichert wird.

3. {{bookId}} im Details-Request: Aufnahme der Variable

Nachdem der Such-Request bookId gespeichert hat, soll der zweite Request (Details) kein „Request mit manueller Eingabe“ mehr sein. Er wird zur Vorlage. Und das ist es, was Ihre Sammlung wirklich portabel macht: Derselbe Request kann heute, morgen und in einer Woche ausgeführt werden – ohne „Kopierritual“.

Die URL des Details-Requests sieht normalerweise etwa so aus:

# Details-Request für ein Buch anhand der zuvor gespeicherten bookId
GET {{baseUrl}}/books/{{bookId}}

Hier haben Sie {{baseUrl}} bereits in der ersten Lektion des Tages in die Umgebung ausgelagert. Und {{bookId}} geben wir jetzt nicht mehr von Hand ein – es erscheint automatisch nach der Ausführung des Suchrequests.

Ein wichtiger Punkt zum Verständnis: Postman führt die Substitution im Moment des Sendens des Requests durch. Wenn die Variable nicht gesetzt ist, „errät“ Postman den Wert nicht, sondern lässt {{bookId}} ehrlich als Text stehen (oder setzt eine leere Zeichenkette ein – je nach Situation). Wenn Sie also eine seltsame URL sehen, sollten Sie als Erstes die aktive Umgebung prüfen und ob dort tatsächlich bookId gespeichert ist.

So erhalten Sie eine Verkettung, die fast wie ein kleiner Backend-Ablauf aussieht: zuerst ein Buch über eine Suche finden, dann anhand der gefundenen ID die Details abfragen.

4. Verkettung und leeres Suchergebnis

Hier ist es wichtig, nicht zu verwechseln: Vollständige Negative-Path-Szenarien werden wir separat besprechen, aber die Request-Kette sollte zumindest nicht „mit dem Gesicht auf der Tastatur landen“, wenn die Suche nichts findet. In der Praxis wird das ständig passieren. Nicht weil die API schlecht ist, sondern weil Benutzer (und Sie) verschiedene Suchbegriffe eingeben werden: mit Tippfehlern, mit seltenen Wörtern, mit leeren Zeichenketten.

Das häufigste Problem bei Verkettungen klingt so: Die Suche liefert eine leere Liste, bookId wird nicht gespeichert, aber der Details-Request wird trotzdem gesendet und geht „auf Details-Suche mit fehlender ID“. Im besten Fall erhalten Sie 404, im schlimmsten Fall einen undurchsichtigen Fehler. Daher brauchen wir eine minimale Disziplin: Wenn nichts zu speichern ist, zeigen wir das deutlich an.

Man kann das Skript etwas erweitern und ein klares Signal hinzufügen:

// Suchergebnisantwort parsen
const body = pm.response.json();

// Wenn items nicht existiert oder leer ist, speichern wir nichts, sondern hinterlassen eine deutliche Spur im Log
if (!body.items || body.items.length === 0) {
  console.log("Suche ergab 0 Elemente. bookId ist nicht gesetzt."); // Hinweis in der Konsole
} else {
  // Ansonsten nehmen wir die ID des ersten Ergebnisses und speichern sie in der Umgebung
  const firstBookId = body.items[0].id;

  pm.environment.set("bookId", firstBookId);
  console.log("Gespeicherte bookId =", firstBookId); // Gespeicherte bookId = BK-101
}

Das ist immer noch eine einfache Logik, ohne „Test-Frameworks“. Sie machen das Verhalten der Kette lediglich vorhersagbar. Wenn Sie etwas strenger vorgehen möchten, können Sie eine Prüfung hinzufügen, die das Problem direkt im Request-Bericht hervorhebt:

// JSON parsen, um es in der Prüfung zu verwenden
const body = pm.response.json();

// Ein kleiner Test: Wenn es keine Ergebnisse gibt, „failen“ wir explizit und stoppen die Kette an diesem Schritt
pm.test("Suche ergab mindestens ein Element", () => {
  if (!body.items || body.items.length === 0) {
    // Der Fehler wird in den Request-Ergebnissen sichtbar, nicht nur in der Konsole
    throw new Error("Nichts gefunden, Kette zu Details kann nicht aufgebaut werden");
  }
});

Wenn Sie sich noch nicht an pm.test gewöhnen möchten, ist das in Ordnung. Aber die Idee an sich ist wichtig: Ein Chained-Szenario sollte ehrlich sein und nicht so tun, als ob Daten immer vorhanden wären.

5. Schema eines Chained-Szenarios

Wenn Sie zum ersten Mal Chained Requests erstellen, fühlt es sich an, als ob „Postman irgendetwas zaubert“. Um diese Magie zu entmystifizieren, ist es hilfreich, den Ablauf als sehr einfaches Diagramm darzustellen. Sie haben nur drei „Entitäten“: den Such-Request, die aktive Umgebung (wie eine kleine Tasche für Variablen) und den Details-Request.

sequenceDiagram
    participant P as Postman
    participant API as Catalog API
    participant ENV as Active Environment

    P->>API: "GET {{baseUrl}}/search?q={{searchQuery}}&limit={{limit}}"
    API-->>P: "200 + JSON (items[])"
    P->>ENV: "set bookId = items[0].id (Tests)"
    P->>API: "GET {{baseUrl}}/books/{{bookId}}"
    API-->>P: "200 + JSON (details)"

Die Bedeutung des Diagramms liegt darin: ENV ist die „Übergabebox“. Wir übertragen Daten nicht von Hand. Wir übertragen sie über eine Variable, die ein Request geschrieben und ein anderer gelesen hat.

Wenn Sie dieses Bild im Kopf behalten, haben Sie keine Angst mehr vor Chained Requests. Dahinter steckt keine geheime Magie: nur „JSON gelesen → Wert gespeichert → Wert eingesetzt“.

6. Variablenhygiene in Postman

Wenn es mehr als zwei Variablen gibt, beginnt das typische Anfängerchaos: Eine Variable heißt id, aber welche genau? Buch? Autor? Request? Und gestern hieß sie noch book_id, heute bookId, und das alles in verschiedenen Requests. Damit die Sammlung verständlich bleibt, sollte man Variablen wie einen Teil des Vertrags Ihrer Postman-Sammlung behandeln.

Die einfachste Regel: Der Variablenname sollte die Frage „Was ist das?“ beantworten. Daher ist bookId viel besser als id. baseUrl ist besser als url. searchQuery ist besser als q. Das ist keine „Ästhetik“, sondern Gehirnökonomie: Sie öffnen die Sammlung nach einer Woche und beginnen keine Detektivermittlung, wer oder was id ist.

Ein weiterer Punkt: Umgebungsvariablen in Postman sind im Wesentlichen Zeichenketten. Auch wenn limit wie eine Zahl aussieht, wird es meistens als "3" gespeichert. Das ist normal, denn in der URL wird ohnehin Text übermittelt. Wundern Sie sich also nicht, wenn ein Wert „wie eine Zeichenkette“ aussieht. Im Rahmen von Postman-Vorlagen ist das zu erwarten.

Es ist praktisch, eine kleine „Bedeutungstabelle“ im Kopf zu haben (nicht unbedingt in einem separaten Dokument – einfach die Struktur merken):

Und noch eine „ewige“ Fehlerquelle: die aktive Umgebung. Eine Variable kann in die Umgebung geschrieben worden sein, aber wenn die Umgebung nicht als aktiv ausgewählt ist oder Sie zu einer anderen gewechselt haben, sehen Sie {{bookId}} als leeren Wert. Daher eine einfache Gewohnheit: Vor dem Start eines Szenarios prüfen Sie, welche Umgebung gerade aktiv ist, so wie ein Fahrer prüft, in welchem Gang das Auto steht. Sonst heißt es später: „Warum fahre ich rückwärts?“

7. Wie hängt das mit ReadLater Starter zusammen

In dieser Phase des Kurses ist Postman Ihr Labor, in dem Sie den Vertrag festhalten, bevor Sie mit dem Schreiben von Java-Code beginnen. Und Chained Requests sind eine Möglichkeit, den Vertrag von „zwei einzelnen Beispielen“ in ein Szenario zu verwandeln, das an die reale Interaktion von Diensten erinnert. Heute bauen Sie die Kette search → details manuell auf, später wird dasselbe im Code passieren: Die Anwendung sucht zuerst nach Büchern und fragt dann anhand der ausgewählten ID die Detailkarte ab.

Das ist auch psychologisch wichtig. Wenn Sie später einen Java-HTTP-Client schreiben, haben Sie bereits ein klares Modell: welcher Request der erste ist, welche Parameter darin vorkommen, welches Feld aus der Antwort benötigt wird und welcher Request der zweite ist. Sie werden die API nicht „im Code erfühlen“ müssen. Und Code, der nach einem klaren Vertrag geschrieben wird, geht seltener kaputt und lässt sich schneller debuggen (und ja, das wirkt sich direkt auf die Anzahl der nervösen Seufzer pro Tag aus).

8. Typische Fehler bei Chained Requests in Postman

Wenn man anfängt, Requests zu verketten, werden die Fehler etwas „tückischer“, weil das Problem möglicherweise nicht in einem bestimmten Request liegt, sondern darin, dass die Kette die Daten nicht weitergegeben hat. Das ist normal: Sie lernen gerade, das Szenario als Ganzes zu sehen. Im Folgenden sind die häufigsten Stolpersteine, auf die fast alle treten (ich eingeschlossen, ich bin nur früher darauf getreten, damit es für Sie einfacher wird).

Fehler Nr. 1: Nicht ein einzelnes Feld, sondern die gesamte Antwort speichern.
Manchmal erscheint es logisch, „das JSON in einer Variable zu speichern“ und daraus später „irgendwie die ID zu holen“. In der Praxis wird daraus schnell ein riesiger String, der schwer zu lesen, schwer zu übertragen und leicht versehentlich zu beschädigen ist. Die Kette sollte den minimal benötigten Wert übergeben. Für details wird bookId benötigt, also speichern wir bookId, nicht das ganze Universum.

Fehler Nr. 2: Den Pfad zum Feld im JSON verwechseln (und undefined speichern).
Das typischste Szenario: Sie schreiben body.items[0].id, aber in Wirklichkeit heißt das Feld key oder das Array heißt docs. Postman speichert brav undefined, und Sie erhalten später eine URL ohne id. Das wird zwar langweilig, aber zuverlässig behoben: Einmal das tatsächliche JSON genau ansehen, das Feld finden und erst dann das Skript schreiben. Wenn Sie unsicher sind, geben Sie vorübergehend console.log(body) aus und sehen Sie sich die Struktur an.

Fehler Nr. 3: Nicht prüfen, ob das Array leer ist.
Wenn die Suche eine leere Liste zurückgibt, liefert der Zugriff auf items[0] undefined, und Sie speichern anschließend „Leere“. Das ist kein „seltener Corner Case“, sondern ein reales Szenario. Eine minimale Absicherung durch if (items.length > 0) macht die Kette vorhersagbar. Auch wenn Sie noch keinen vollständigen Negative-Path-Testsatz haben, sollte sich die Kette sauber verhalten.

Fehler Nr. 4: Einen zu allgemeinen Variablennamen verwenden (id).
Die Variable id lebt genau so lange, bis Sie eine zweite id eines anderen Typs hinzufügen. Danach beginnen seltsame Effekte: Sie denken, Sie speichern die id eines Buches, aber in Wirklichkeit liegt dort die id eines Autors aus einem anderen Request, weil Sie den Namen wiederverwendet haben. Eine gute Sammlung liest sich wie ein Text: bookId, searchQuery, baseUrl. Ja, das ist etwas länger, aber dafür überhitzt das Gehirn nicht.

Fehler Nr. 5: Vergessen, die aktive Umgebung auszuwählen.
Das Skript kann einwandfrei ausgeführt werden, aber wenn Sie den Request ohne ausgewählte Umgebung oder mit einer anderen Umgebung ausführen, wird die Variable nicht dort gespeichert (oder ist überhaupt nicht sichtbar). Und Sie haben das Gefühl, Postman „spinnt“. In der Praxis ist das fast nie ein Spinne, sondern einfach die falsche aktive Umgebung. Gewohnheit: Vor dem Klicken auf Senden einen Blick auf die Dropdown-Liste der Umgebungen werfen.