Einige Anfragen müssen bearbeitet werden, bevor sie Ihre Maschine verlassen, andere direkt nach dem Eintreffen der Antwort. Eine Zahlungs-API benötigt etwa eine HMAC-Signatur aus Zeitstempel und Geheimnis. Ein Login-Endpunkt liefert einen Token zurück, den spätere Aufrufe benötigen. Und ein Bestellvorgang sollte prüfen, ob tatsächlich ein 200-Status sowie die erwartete Bestell-ID zurückgegeben wurden. Manuell funktioniert das, wird im Team aber schnell fehleranfällig und aufwendig.
Skripte automatisieren diese Schritte. In Apidog hängen Sie kleine JavaScript-Blöcke an eine Anfrage an: einen vor dem Senden und einen nach dem Empfang der Antwort. Wenn Sie bereits Postman-Skripte geschrieben haben, ist die API vertraut, da Apidog mit derselben pm-Objekt-API kompatibel ist.
Dieser Leitfaden zeigt zwei typische Aufgaben:
- Eine Anfrage im Pre Processor mit HMAC signieren.
- Einen Token im Post Processor prüfen und für weitere Anfragen speichern.
Die Details beschreibt die Apidog-Skriptdokumentation. Wichtig sind jedoch die abweichenden Tab-Namen und einige Verhaltensunterschiede zu Postman.
Was Pre- und Post-Skripte tatsächlich tun
Apidog führt Skripte in zwei klar getrennten Phasen aus.
Pre Processors
Pre Processors laufen, bevor die Anfrage an den Server gesendet wird. Verwenden Sie sie, um die Anfrage vorzubereiten:
- Zeitstempel erzeugen
- HMAC-Signaturen berechnen
- zufällige Bestell- oder Request-IDs setzen
- Variablen in Header- oder Body-Werte umwandeln
Eine Antwort existiert in dieser Phase noch nicht. Code, der eine Antwort auswertet, gehört daher nicht in einen Pre Processor.
Post Processors
Post Processors laufen, nachdem die Antwort eingetroffen ist. Hier können Sie:
- Statuscodes und Antwortdaten per Assertion prüfen
- Tokens, Ressourcen-IDs oder Cursor extrahieren
- Werte für spätere Anfragen speichern
- Antwortzeiten und Header auswerten
Daraus ergeben sich zwei praktische Regeln:
-
pm.responsefunktioniert nur in Post Processors. Dazu gehören unter anderemcode,status,headers,responseTime,responseSize,text()undjson(). - Variablen verbinden beide Phasen: Ein Pre Processor setzt einen Wert, die Anfrage verwendet ihn, und ein Post Processor kann ihn lesen oder überschreiben.
Wenn Sie von Postman kommen: In Apidog heißen die Tabs Pre Processors und Post Processors, nicht „Pre-request Script“ und „Tests“.
Einrichtung: Anfrage öffnen und Skript-Tabs finden
Installieren Sie Apidog über Apidog herunterladen, falls Sie es noch nicht verwenden.
Öffnen Sie anschließend die Anfrage, die Sie automatisieren möchten. Neben Params, Headers und Body finden Sie die Tabs:
- Pre Processors
- Post Processors
Öffnen Sie den gewünschten Tab und wählen Sie add a Custom Script. Im Editor schreiben Sie JavaScript gegen das pm-Objekt.
Bevor Sie beginnen, beachten Sie die Variablenpriorität:
Lokale Variablen > Umgebungsvariablen > globale, projektweit geteilte Variablen > globale, teamweit geteilte Variablen
Ein lokaler Wert überdeckt also eine Umgebungsvariable mit demselben Namen. Wenn eine Variable einen unerwarteten Wert liefert, prüfen Sie zuerst, ob ein höher priorisierter Scope sie überschreibt.
Für stabile, projektweite Einstellungen eignen sich globale Parameter in Apidog.
Pre Processor: Eine Anfrage mit HMAC signieren
Angenommen, ein Zahlungs-Endpunkt erwartet pro Anfrage:
- einen Unix-Zeitstempel
- eine HMAC-SHA256-Signatur aus Zeitstempel, Request-Body und API-Geheimnis
Dieses Muster ist auch bei Webhook-Signaturen üblich. Die Signaturdokumentation von Stripe beschreibt ein vergleichbares Verfahren.
Öffnen Sie Pre Processors, wählen Sie add a Custom Script und fügen Sie dieses Skript ein:
// Pre Processor: die Anfrage signieren, bevor sie gesendet wird
const CryptoJS = require('crypto-js');
// aktueller Unix-Zeitstempel in Sekunden
const timestamp = Math.floor(Date.now() / 1000).toString();
// das Geheimnis aus einer Umgebungsvariable lesen
const secret = pm.environment.get('payments_api_secret');
// die zu signierende Zeichenfolge erstellen: Zeitstempel + Zeilenumbruch + roher Body
const body = pm.request.body ? pm.request.body.toString() : '';
const payload = timestamp + '\n' + body;
// die HMAC-SHA256-Signatur berechnen, hex-kodiert
const signature = CryptoJS.HmacSHA256(payload, secret).toString(CryptoJS.enc.Hex);
// beide Werte als Umgebungsvariablen für die Anfrage speichern
pm.environment.set('x_timestamp', timestamp);
pm.environment.set('x_signature', signature);
pm.console.log('Anfrage signiert am ' + timestamp);
Das Skript speichert Zeitstempel und Signatur als Umgebungsvariablen. Verwenden Sie diese Variablen im Tab Headers:
X-Timestamp: {{x_timestamp}}
X-Signature: {{x_signature}}
Beim Senden ist die Reihenfolge:
- Apidog führt den Pre Processor aus.
- Das Skript setzt
x_timestampundx_signature. - Apidog ersetzt
{{x_timestamp}}und{{x_signature}}in den Headern. - Der Server erhält die aktuelle Signatur.
Für crypto-js verwenden Sie immer das vollständige Modul:
const CryptoJS = require('crypto-js');
Ein Untermodulpfad wie dieser funktioniert nicht:
require('crypto-js/sha256');
Variablenoperationen ändern nur aktuelle Werte, nicht die im Umgebungseditor hinterlegten Anfangswerte. Das passt für flüchtige Daten wie Zeitstempel und Signaturen.
Wenn Sie dieselbe Logik mit Postman-Begriffen vergleichen möchten, behandelt der Leitfaden zu Postman Pre-request-Skripten das gleiche Grundprinzip.
Post Processor: Token extrahieren und Antwort prüfen
Nehmen wir an, Ihre Login-Anfrage liefert diese Antwort:
{
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"user": { "id": 4812, "email": "dana@example.com" },
"expires_in": 3600
}
Öffnen Sie Post Processors, wählen Sie add a Custom Script und fügen Sie Folgendes ein:
// Post Processor: die Antwort verifizieren, dann den Token extrahieren
pm.test('Status ist 200', function () {
pm.response.to.have.status(200);
});
const jsonData = pm.response.json();
pm.test('Antwort gibt einen Token zurück', function () {
pm.expect(jsonData.token).to.be.a('string').and.not.empty;
});
pm.test('Benutzer-ID ist vorhanden', function () {
pm.expect(jsonData.user.id).to.be.a('number');
});
// den Token speichern, damit andere Anfragen ihn senden können
pm.environment.set('auth_token', jsonData.token);
pm.console.log('Token für Benutzer ' + jsonData.user.email + ' gespeichert');
Das Skript erledigt zwei Aufgaben:
- Die
pm.test()-Blöcke prüfen Statuscode und Datenstruktur. -
pm.environment.set('auth_token', jsonData.token)speichert den Token für weitere Anfragen.
Verwenden Sie den gespeicherten Wert anschließend in geschützten Endpunkten:
Authorization: Bearer {{auth_token}}
Damit entfällt das manuelle Kopieren des Tokens.
Für umfangreichere Prüfungen lesen Sie den Leitfaden zu API-Assertions in Apidog. Wenn Sie Testdaten dynamisch erzeugen möchten, ergänzt Faker.js in Apidog diesen Workflow.
Beachten Sie außerdem:
-
pm.iterationDataist schreibgeschützt. Sie können Testdaten lesen, aber nicht zurückschreiben. -
pm.cookiesenthält Cookies aus der Antwort, nicht Cookies, die mit der Anfrage gesendet wurden.
Logik mit Public Scripts wiederverwenden
Wenn mehrere Endpunkte dieselbe HMAC-Logik verwenden, kopieren Sie das Skript nicht in jede Anfrage. Nutzen Sie stattdessen Public Scripts.
Erstellen Sie ein Public Script unter:
Settings > Public Scripts
Fügen Sie es danach in den Tab Pre Processors oder Post Processors einer Anfrage ein.
Die Reihenfolge ist wichtig:
- Public Scripts laufen vor Custom Scripts in derselben Prozessorliste.
- Mehrere Public Scripts laufen von oben nach unten.
Wenn ein Custom Script eine Funktion aus einem Public Script aufrufen soll, muss die Funktion global verfügbar sein. Eine Funktion mit const, let oder var bleibt lokal im jeweiligen Skript.
Public Script:
// sign() global machen, indem das Schlüsselwort weggelassen wird
sign = function (payload, secret) {
const CryptoJS = require('crypto-js');
return CryptoJS.HmacSHA256(payload, secret).toString(CryptoJS.enc.Hex);
};
Custom Script darunter:
const timestamp = Math.floor(Date.now() / 1000).toString();
const secret = pm.environment.get('payments_api_secret');
pm.environment.set('x_timestamp', timestamp);
pm.environment.set('x_signature', sign(timestamp, secret));
Fügen Sie zuerst das Public Script ein und platzieren Sie das Custom Script darunter. Andernfalls ist sign() noch nicht definiert.
Bibliotheken, externe Pakete und Debugging
Apidog bündelt mehrere Bibliotheken, die Sie ohne zusätzliche Installation mit require() laden können:
-
crypto-js(v3.1.9-1) für Hashing und HMAC -
jsrsasign(v10.3.0) für JWT- und RSA-Aufgaben, benötigt Apidog 1.4.5 oder neuer -
chai(v4.2.0) für Assertions -
lodash,moment,uuid,xml2js,cheerio,postman-collection,atob,btoa,csv-parse/lib/sync,tv4,ajv - Node-Built-ins wie
path,assert,buffer,util,url,querystring,streamundevents
Benötigen Sie ein nicht gebündeltes Paket, laden Sie es zur Laufzeit mit $$.liveRequire():
$$.liveRequire('nanoid', (nanoid) => {
const id = nanoid.nanoid();
pm.environment.set('request_id', id);
});
Dafür ist eine Internetverbindung erforderlich, weil Apidog das Paket beim Ausführen herunterlädt. Gebündelte Bibliotheken funktionieren ohne Netzwerkzugriff.
Skripte debuggen
Verwenden Sie pm.console.log() oder console.log(), um Werte auszugeben:
pm.console.log('Berechnete Signatur:', signature);
console.log('Antwortdaten:', jsonData);
Die Ausgabe erscheint in der Apidog-Konsole. Das ist besonders hilfreich, um Signaturen, Tokens oder Variablenwerte vor und nach einer Anfrage zu prüfen.
Beachten Sie zwei weitere Einschränkungen:
-
pm.sendRequest()verwendet Callbacks, nicht Promises. Verwenden Sie daher keinawait. -
pm.nextRequest()aus Postman wird nicht unterstützt.
Für mehrstufige Abläufe mit Bedingungen und Verzweigungen verwenden Sie stattdessen Test-Szenarien. Dort können Sie Anfragen visuell mit Bedingungs- und If-Else-Schritten verketten.
Den Workflow mit der Apidog CLI automatisieren
Pre und Post Processors laufen nicht nur beim manuellen Senden. Wenn Sie Anfragen und Assertions in einem gespeicherten Test-Szenario bündeln, kann die Apidog CLI das Szenario ohne GUI ausführen — einschließlich aller Processor-Skripte.
Installieren und authentifizieren Sie die CLI:
npm install -g apidog-cli
apidog login --with-token
apidog run --access-token $APIDOG_ACCESS_TOKEN -t -e -r cli
Die relevanten Optionen:
-
-t: ID des Test-Szenarios -
-e: ID der Umgebung -
-r: Reporter, etwacli,htmloderjunit
Mehrere Reporter können Sie durch Kommas trennen.
Erzeugen Sie den Access Token in den Apidog-Kontoeinstellungen und exportieren Sie ihn als Umgebungsvariable:
export APIDOG_ACCESS_TOKEN="Ihr-Token"
Dadurch läuft dieselbe Signatur-, Assertion- und Token-Logik auch in Ihrer CI-Pipeline.
Achten Sie darauf, dass Ihre Skripte keine rein lokalen Abhängigkeiten benötigen. Ein Skript kann in der Desktop-App funktionieren, aber in der CLI fehlschlagen, wenn etwa eine lokale Datei oder ein zuvor manuell geladenes Paket fehlt. Verwenden Sie möglichst gebündelte Bibliotheken oder $$.liveRequire().
Häufig gestellte Fragen
Sind Apidog-Skripte mit bestehenden Postman-Skripten kompatibel?
Meistens ja. Apidog verwendet dieselbe pm-Objekt-API. Bekannte Aufrufe wie diese funktionieren daher wie erwartet:
pm.environment.set('name', 'value');
pm.response.json();
pm.test('Beschreibung', function () {});
pm.expect(value).to.exist;
Achten Sie auf die unterschiedlichen Tab-Namen sowie nicht unterstützte APIs wie pm.nextRequest().
Warum ist pm.response im Pre Processor undefined?
Weil noch keine Antwort existiert. Pre Processors laufen vor dem Senden der Anfrage. Code, der Status, Header oder Body der Antwort liest, gehört in einen Post Processor.
Für Daten vor dem Senden verwenden Sie stattdessen pm.request, Variablen oder Bibliotheken. Informationen dazu, wie Sie Request-Daten lesen, finden Sie unter Request-Parameter in Pre- und Post-Request-Skripten abrufen.
Wie teile ich ein Skript über mehrere Anfragen?
Verwenden Sie Public Scripts unter Settings > Public Scripts. Schreiben Sie die Logik einmal und fügen Sie sie in den jeweiligen Pre oder Post Processor ein.
Public Scripts laufen vor Custom Scripts. Funktionen, die ein Custom Script verwenden soll, müssen global definiert sein:
myHelper = function () {
// ...
};
Kann ich ein npm-Paket importieren, das nicht gebündelt ist?
Ja, mit $$.liveRequire():
$$.liveRequire('package-name', (pkg) => {
// pkg verwenden
});
Dafür wird eine Internetverbindung benötigt. Für gebündelte Pakete wie crypto-js, moment oder uuid genügt require().
Sie können nur vollständige Module laden, keine Untermodulpfade.
Wo sehe ich die Ausgabe meines Skripts?
Verwenden Sie:
pm.console.log('Debug-Ausgabe');
oder:
console.log('Debug-Ausgabe');
Die Ausgabe finden Sie nach dem Senden in der Apidog-Konsole.
Zusammenfassung
Pre Processors und Post Processors machen aus statischen API-Anfragen wiederverwendbare, überprüfbare Abläufe:
- Signieren und vorbereiten, bevor Sie senden.
- Antworten prüfen und Werte extrahieren, nachdem sie eintreffen.
- Tokens, IDs und Cursor in Variablen speichern.
- Wiederverwendbare Logik als Public Scripts zentralisieren.
- Szenarien mit der CLI in CI ausführen.
Öffnen Sie Apidog, wählen Sie eine Anfrage und beginnen Sie mit einem kleinen Custom Script — etwa einem Zeitstempel im Pre Processor oder einer Statuscode-Assertion im Post Processor.
Top comments (0)