Replays aufzeichnen und ansehen

Ein Replay ist eine aufgezeichnete Antwort, die bei passenden Anfragen erneut ausgeliefert wird: einmal aufzeichnen, danach immer wiedergeben, wie ein Videorekorder. Der erste passende Aufruf speichert, was die Simulation geantwortet hat, generiert oder vom Upstream geholt; jeder spätere passende Aufruf bekommt genau diese Antwort zurück, markiert mit dem Header X-Mockzilla-Source: replay. Nutze es, um eine Payload über Testläufe stabil zu halten, die Antwort eines echten Backends einmal einzufangen und dann ohne es zu arbeiten, oder um die exakte Antwort von Hand zu bauen, die ein Ablauf braucht.

Wie eine Aufzeichnung gematcht wird

Jede Aufzeichnung liegt unter einem Key aus der Methode, dem Pfadmuster und den Anfragefeldern, die du wählst:

• Body-Felder sind punktierte JSON-Pfade (name, data.address.zip, items[0].sku) oder Formularfeld-Namen.
• Query-Parameter kommen aus dem Query-String der URL.
• Pfad-Parameter sind die {platzhalter}-Werte im Pfad. Sie werden ignoriert, solange sie nicht gelistet sind: standardmäßig teilen sich /pets/1 und /pets/2 eine Aufzeichnung, mit gelistetem petId bekommt jede id ihre eigene.
• Gar keine Felder heißt nur Pfad: Jede Anfrage an den Endpunkt teilt sich eine einzige Aufzeichnung.

Nur die gewählten Felder zählen; alles andere in der Anfrage wird ignoriert. Zwei Anfragen mit denselben Werten in diesen Feldern bekommen dieselbe Aufzeichnung. Fehlt ein gewähltes Feld in einer Anfrage, überspringt Replay sie komplett: Nichts wird aufgezeichnet und nichts wiedergegeben.

Aufzeichnen ohne jede Einrichtung

Der schnellste Weg braucht keine Konfiguration: Schicke den Header X-Mockzilla-Replay. Das funktioniert auf jeder deployten Simulation.

# Erster Aufruf: zeichnet die Antwort auf (Match auf das Body-Feld "name")
curl -X POST "https://api.mockz.io/app/deine-org/deine-sim/petstore/pets" \
  -H "Content-Type: application/json" \
  -H "X-Mockzilla-Replay: name" \
  -d '{"name": "Rex", "tag": "checkout-flow"}'

# Jeder spätere Aufruf mit name=Rex: liefert exakt dieselbe Antwort
curl -X POST "https://api.mockz.io/app/deine-org/deine-sim/petstore/pets" \
  -H "Content-Type: application/json" \
  -H "X-Mockzilla-Replay: name" \
  -d '{"name": "Rex", "tag": "anderer-tag-ist-egal"}'

Schau in die Antwort-Header: Der erste Aufruf sagt X-Mockzilla-Source: generated (oder upstream), der zweite X-Mockzilla-Source: replay.

Der Header benennt die Felder, auf die gematcht wird. Nackte Namen sind Body-Felder; Präfixe wählen andere Quellen, ; trennt sie:

# Leer: nutzt den in der App konfigurierten Match-Key, sonst nur Pfad
-H "X-Mockzilla-Replay:"

# Zwei Body-Felder
-H "X-Mockzilla-Replay: biller,reference"

# Body-, Query- und Pfad-Felder zusammen
-H "X-Mockzilla-Replay: body:reference;query:channel;path:paymentMethod"

In der App einrichten

Konfiguration ersetzt den Header: Clients rufen die Simulation wie jede andere API auf, und die Aufzeichnungsregeln wohnen bei der Simulation. Öffne Replays in der Seitenleiste und wähle einen Service.

1. Schalte das Aufzeichnen ein. Der App-Standard gilt für jeden Service; ein Service kann ihn überschreiben. Die Plakette neben dem Titel sagt, ob Aufzeichnung für das Gewählte aktiv ist.
2. Wähle einen Endpunkt und setze seinen Match-Key. Die Tabelle zeigt jeden Endpunkt, seinen Match-Key und wie viele Aufzeichnungen er hält. Klick auf eine Zeile:

Der Editor zeigt den exakten X-Mockzilla-Replay-Header für den Key, den du baust, bereit zum Kopieren. Replay hier aktivieren schaltet den einzelnen Endpunkt ein; Endpunkte ohne Match-Key teilen sich schlicht eine Aufzeichnung pro Pfad.

1. Auto-Replay, in den Service-Einstellungen, zeichnet konfigurierte Endpunkte ohne jeden Header auf und gibt sie wieder. Schalte es ein, wenn der aufrufende Code nicht änderbar ist.
2. Nur Upstream aufzeichnen ist zum Einfangen eines echten Backends: Generierte Antworten werden nicht aufgezeichnet und liefern stattdessen einen 502, damit sich eine Aufnahmesession nicht still mit Mock-Daten füllt.
3. TTL bestimmt, wie lange Upstream-Aufzeichnungen leben, mit dem App-Standard von 24 Stunden als Rückfall.

Aufzeichnungen ansehen und bearbeiten

Das Panel eines Endpunkts listet seine Aufzeichnungen nach Match-Werten, Status und Quelle: Upstream kam von einem echten Backend, generiert vom Mock, manuell wurde von Hand geschrieben.

• Bearbeite Status, Inhaltstyp oder Body und speichere; die Laufzeit liefert ab dann die geänderte Antwort für diesen Key. Einmal aufzeichnen und dann die Payload anpassen ist oft schneller, als sie von Grund auf zu bauen.
• Neue Aufzeichnung legt eine von Hand an, bevor es Traffic gibt: Setze die Match-Werte, den Status und den Body, und der Endpunkt antwortet damit ab der ersten Anfrage.
• Aufzeichnung löschen entfernt einen Key; Alle löschen leert den Endpunkt.
• Upstream-Aufzeichnungen laufen nach der TTL ab. Manuelle und generierte haben keine TTL und bleiben bis zum Löschen.

Eine Aufzeichnung, die per Ad-hoc-Header auf einem Pfad ohne konfigurierten Endpunkt entstand, taucht hier trotzdem auf, gruppiert unter ihrem Pfad; nichts Aufgezeichnetes ist unsichtbar.

Wiedergegebene Aufrufe erscheinen im Verlauf wie jede andere Anfrage; der Antwort-Header ist es, der das Replay als Quelle benennt.

Siehe Verlauf.

Was gewinnt, wenn Features sich stapeln

Ein Replay-Treffer antwortet früh: Passt eine Aufzeichnung, liefert sie, vor dem Cache und bevor der Upstream kontaktiert wird. Ohne passende Aufzeichnung läuft die Anfrage normal weiter, und auf dem Rückweg wird die Antwort fürs nächste Mal eingefangen. Latenz- und Fehlerinjektion greifen weiter auf dem Hinweg, ein Endpunkt mit Replay kann also trotzdem absichtlich langsam sein oder fehlschlagen.

Aufzeichnungen zwischen Simulationen bewegen oder mit dem Team teilen hat eine eigene Seite.

Siehe Replays exportieren und importieren.