Einige Anfragen müssen bearbeitet werden, bevor sie Ihre Maschine verlassen, und einige müssen in dem Moment bearbeitet werden, in dem eine Antwort eintrifft. Eine Zahlungs-API benötigt eine HMAC-Signatur, die aus einem Zeitstempel und Ihrem Geheimnis berechnet wird. Ein Login-Endpunkt gibt einen Token zurück, den jeder spätere Aufruf benötigt. Ein Bestellvorgang muss sicherstellen, dass die Antwort tatsächlich einen 200-Status und die richtige Bestell-ID zurückgegeben hat. All dies können Sie manuell erledigen, aber das wird schnell mühsam und geht kaputt, sobald Sie die Anfrage mit einem Teamkollegen teilen.
Skripte beheben das. In Apidog fügen Sie kleine JavaScript-Codeblöcke an eine Anfrage an, die automatisch ausgeführt werden: eine Reihe, bevor die Anfrage gesendet wird, und eine weitere, nachdem die Antwort zurückkommt. Wenn Sie bereits Postman-Skripte geschrieben haben, überträgt sich die Routine, da die Engine von Apidog mit derselben pm-Objekt-API kompatibel ist. Dieser Leitfaden führt Sie anhand eines realistischen Beispiels durch beide Phasen: das Signieren einer Anfrage in einem Pre-Request-Skript und das Extrahieren eines Tokens in einem Post-Response-Skript. Das Verhalten ist vollständig in der Apidog-Skriptdokumentation beschrieben, aber die Tab-Namen und einige Verhaltensweisen unterscheiden sich von Postman, und diese Unterschiede sind wichtig.
Was Pre- und Post-Skripte tatsächlich tun
Apidog führt Skripte in zwei Phasen aus und benennt diese klar.
Pre Processors werden ausgeführt, bevor die Anfrage an den Server gesendet wird. Hier bereiten Sie Dinge vor: Erzeugen Sie einen Zeitstempel, berechnen Sie eine Signatur, legen Sie eine zufällige Bestell-ID fest oder lesen Sie eine Variable und formatieren Sie sie zu einem Header. Die Antwort existiert zu diesem Zeitpunkt noch nicht, daher ist alles, was eine Antwort inspiziert, hier tabu.
Post Processors werden ausgeführt, nachdem die Antwort empfangen wurde. Hier überprüfen Sie, was mit Assertions zurückkam, und ziehen Werte aus dem Body, um sie später wiederzuverwenden. Extrahieren Sie einen Authentifizierungstoken, rufen Sie eine neu erstellte Ressourcen-ID ab, überprüfen Sie den Statuscode, speichern Sie einen Cursor für die Paginierung.
Aus dieser Aufteilung ergeben sich zwei Regeln. Erstens funktioniert pm.response (mit seinen Eigenschaften code, status, headers, responseTime, responseSize, text() und json()) nur in Post Processors. Es gibt keine Antwort zum Lesen, bevor Sie senden, daher wird ein Aufruf in einem Pre Processor Ihnen nicht helfen. Zweitens sind Variablen die Art und Weise, wie die beiden Phasen miteinander kommunizieren. Ein Pre Processor setzt einen Wert, die Anfrage verwendet ihn, und ein Post Processor kann ihn lesen oder überschreiben.
Wenn Sie von Postman kommen, beachten Sie gleich die Namensänderung. Die Tabs von Apidog sind Pre Processors und Post Processors, nicht „Pre-request Script“ und „Tests“. Das Verhalten ist sehr ähnlich, aber die Bezeichnungen auf dem Bildschirm sind unterschiedlich.
Einrichtung: Eine Anfrage öffnen und die Tabs finden
Laden Sie Apidog herunter, um mitzumachen. Es ist kostenlos und läuft auf macOS, Windows und Linux, also holen Sie es sich von der Seite Apidog herunterladen, falls Sie es noch nicht haben.
Öffnen Sie die API-Anfrage, die Sie in Apidog skripten möchten. Jeder Endpunkt hat einen Tab Pre Processors und einen Tab Post Processors neben den üblichen Tabs Params, Headers und Body. Um Logik zu einer der beiden Phasen hinzuzufügen, öffnen Sie den Tab und wählen Sie add a Custom Script. Dadurch öffnet sich ein Code-Editor, in dem Sie reines JavaScript für das pm-Objekt schreiben.
Bevor Sie etwas schreiben, ist es hilfreich zu wissen, wo Werte gespeichert sind. Apidog löst Variablen in dieser Prioritätsreihenfolge auf:
Lokale Variablen > Umgebungsvariablen > Globale Variablen, die projektweit geteilt werden > Globale Variablen, die teamweit geteilt werden.
Eine lokale Variable hat also Vorrang vor einer Umgebungsvariablen desselben Namens und so weiter. Beachten Sie dies, wenn ein Wert nicht Ihren Erwartungen entspricht: Etwas Höheres in der Reihenfolge überdeckt ihn wahrscheinlich. Wenn Sie Werte benötigen, die über viele Anfragen hinweg bestehen bleiben, befinden sich globale Parameter in Apidog niedriger in der Prioritätsreihenfolge und eignen sich gut für stabile, projektweite Einstellungen.
Pre Processor Beispiel: Eine Anfrage mit HMAC signieren
Angenommen, Sie rufen einen Zahlungs-Endpunkt auf, der jede Anfrage mit einer HMAC-SHA256-Signatur authentifiziert. Dies ist dasselbe Muster, das viele Anbieter zur Webhook-Verifizierung verwenden, und die Signaturdokumentation von Stripe beschreibt es gut: Der Server erwartet einen Zeitstempel und eine Signatur, die aus diesem Zeitstempel plus dem Anfragetext berechnet und mit Ihrem API-Geheimnis verschlüsselt wird. Sie müssen beides bei jedem Senden neu erstellen.
Apidog liefert crypto-js als integrierte Bibliothek, sodass Sie nichts installieren müssen. Öffnen Sie den Tab Pre Processors, wählen Sie add a Custom Script und schreiben Sie dies:
// 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);
Dieses Skript berechnet die Signatur und speichert sowohl den Zeitstempel als auch die Signatur in Umgebungsvariablen. Verbinden Sie diese nun mit der Anfrage. Im Tab Headers verweisen Sie auf die gespeicherten Werte mit der Syntax {{variableName}}:
X-Timestamp: {{x_timestamp}}
X-Signature: {{x_signature}}
Wenn Sie senden, führt Apidog zuerst den Pre Processor aus, setzt die beiden Variablen und ersetzt sie dann in den Headern. Der Server erhält bei jedem Senden eine zum Sendezeitpunkt gültige Signatur, ohne dass ein manueller Schritt erforderlich ist. Beachten Sie, dass der Aufruf require('crypto-js') das gesamte Modul lädt. Sie importieren die gesamte Bibliothek, nicht ein Untermodul, daher funktioniert require('crypto-js') und require('crypto-js/sha256') nicht.
Eines ist zu beachten: Variablenoperationen wirken sich nur auf aktuelle Werte aus, nicht auf die Anfangswerte, die Sie möglicherweise in den Umgebungseditor eingegeben haben. Das ist hier gewollt, da die Signatur flüchtig sein soll. Wenn Sie auch Signaturmuster für die Postman-Seite erklärt benötigen, behandelt die Anleitung zu Postman Pre-request-Skripten dieselbe Idee mit den Bezeichnungen von Postman, und sie lässt sich nahtlos auf die Pre Processors von Apidog übertragen.
Post Processor Beispiel: Ein Token extrahieren und verifizieren
Nun die andere Phase. Stellen Sie sich eine Login-Anfrage vor, die einen Token zurückgibt, den Sie für jeden späteren authentifizierten Aufruf benötigen:
{
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"user": { "id": 4812, "email": "dana@example.com" },
"expires_in": 3600
}
Öffnen Sie den Tab Post Processors, wählen Sie add a Custom Script und extrahieren Sie den Token aus dem Body, um ihn für spätere Anfragen zu speichern:
// 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');
Hier passieren zwei Dinge. Die pm.test()-Blöcke bestätigen, dass die Antwort die erwartete Form hat, indem sie Chai-artige pm.expect()-Matcher verwenden, die Apidog nativ unterstützt. Und pm.environment.set('auth_token', jsonData.token) speichert den Token in der Umgebung. Jede spätere Anfrage kann nun Authorization: Bearer {{auth_token}} senden, ohne dass Sie etwas manuell kopieren müssen.
Die Assertions-Hälfte verdient für sich genommen Beachtung. Gute Post-Response-Überprüfungen verwandeln ein manuelles Klicken und Überprüfen in einen echten Test, und unser Leitfaden zu API-Assertions in Apidog geht tiefer auf die wichtigen Matcher und Muster ein. Wenn Sie auch realistische simulierte Daten in diese Abläufe einspeisen möchten, passt Faker.js in Apidog gut zur oben gezeigten Variableneinstellung.
Ein paar Verhaltensweisen, die in Post Processors zu beachten sind. pm.iterationData (Ihre Testdaten) ist schreibgeschützt, sodass Sie einen datengesteuerten Wert lesen, aber nicht über ein Skript zurückschreiben können. Und pm.cookies gibt das Cookie aus der Antwort zurück, das der Server gesendet hat, nicht das Cookie, das mit Ihrer Anfrage gesendet wurde.
Logik mit Public Scripts wiederverwenden
Sobald Sie diesen HMAC-Signaturblock geschrieben haben, möchten Sie ihn wahrscheinlich für mehr als eine Anfrage verwenden. Das Kopieren und Einfügen in zehn Endpunkte bedeutet zehn Stellen, die bei einer Algorithmusänderung behoben werden müssen. Apidog's Antwort sind Public Scripts: wiederverwendbare Snippets, die Sie einmal schreiben und bei Bedarf anfügen.
Erstellen Sie einen unter Settings > Public Scripts und fügen Sie ihn dann zum Tab Pre Processors oder Post Processors einer Anfrage hinzu. Innerhalb einer Prozessorliste befinden sich ein Public Script und ein Custom Script nebeneinander, und die Reihenfolge ist wichtig: Public Scripts werden vor Custom Scripts in derselben Liste ausgeführt, und wenn Sie mehrere Public Scripts haben, werden sie in der angegebenen Reihenfolge von oben nach unten ausgeführt.
Es gibt eine Falle, die viele stolpern lässt. Wenn ein Custom Script eine Funktion aufrufen soll, die in einem Public Script definiert ist, muss diese Funktion global sein. Eine normale function-Deklaration oder eine mit const gebundene Funktion ist lokal für ihr eigenes Skript und für das nächste unsichtbar. Deklarieren Sie sie, indem Sie sie ohne var, let oder const zuweisen:
// Im 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);
};
// Im Custom Script darunter: die globale Funktion beim Namen aufrufen
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 hinzu, platzieren Sie das Custom Script darunter, und der Aufruf wird aufgelöst. Wenn die Reihenfolge falsch ist oder Sie ein const hinzufügen, erhalten Sie einen Fehler wegen einer undefinierten Funktion.
Bibliotheken, externe Pakete und Debugging
Der obige Import von crypto-js ist eine von mehreren Bibliotheken, die Apidog ohne Einrichtung bündelt. Sie können jede davon direkt require():
crypto-js(v3.1.9-1) für Hashing und HMACjsrsasign(v10.3.0) für JWT- und RSA-Arbeiten, erfordert Apidog 1.4.5 oder neuerchai(v4.2.0) für die Assertions-Matcherlodash,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
Wenn Sie etwas benötigen, das nicht auf dieser Liste steht, können Sie es zur Laufzeit mit $$.liveRequire() einbinden, das das Paket spontan abruft:
$$.liveRequire('nanoid', (nanoid) => {
const id = nanoid.nanoid();
pm.environment.set('request_id', id);
});
Dieser Pfad benötigt eine Internetverbindung, da Apidog das Paket herunterlädt, wenn das Skript ausgeführt wird. Die gebündelten Bibliotheken benötigen dies nicht.
Wenn sich ein Skript falsch verhält, protokollieren Sie Ihren Weg heraus. Sowohl pm.console.log() als auch das einfache console.log() geben Ausgaben in die Konsole von Apidog aus, sodass Sie eine berechnete Signatur oder ein extrahiertes Feld ausgeben und genau sehen können, was das Skript produziert hat, bevor die Anfrage gesendet wird oder nachdem sie zurückkehrt.
Zwei weitere Einschränkungen, die es wert sind, genannt zu werden, damit sie Sie nicht überraschen. pm.sendRequest(), zum Auslösen eines zusätzlichen HTTP-Aufrufs innerhalb eines Skripts, verwendet ein Callback-Muster statt Promises, schreiben Sie es also mit einem Callback, nicht mit await. Und Postmans pm.nextRequest() zum Verketten von Anfragen wird hier nicht unterstützt. Wenn Sie eine echte Workflow-Orchestrierung mit Verzweigungen und bedingten Schritten benötigen, verwendet Apidog stattdessen Test-Szenarien, bei denen Sie Anfragen visuell mit Bedingungs- und If-Else-Schritten sequenzieren. Wenn Sie viele Skripte schreiben, kann der integrierte Apidog Script Generator auch eines aus einer natürlichsprachlichen Beschreibung erstellen, um Ihnen einen Ausgangspunkt zu geben.
Den Workflow mit der Apidog CLI automatisieren
Skripte werden nicht nur ausgeführt, wenn Sie auf Senden klicken. Wenn Sie Ihre Anfragen und Assertions in einem gespeicherten Test-Szenario bündeln, führt die Apidog CLI dieses gesamte Szenario ohne GUI aus, einschließlich Pre Processors und Post Processors. Dies macht Ihre Signatur- und Token-Extraktionslogik zu einem Teil der CI statt eines manuellen Schritts.
Installieren und authentifizieren Sie die CLI, dann führen Sie ein Szenario anhand der ID aus:
npm install -g apidog-cli
apidog login --with-token
apidog run --access-token $APIDOG_ACCESS_TOKEN -t -e -r cli
Das Flag -t ist die ID des Testszenarios, -e ist die Umgebung-ID, und -r wählt den Reporter (cli, html oder junit, durch Kommas getrennt für mehrere). Erzeugen Sie den Access Token in Ihren Apidog-Kontoeinstellungen, exportieren Sie ihn als APIDOG_ACCESS_TOKEN, und dasselbe Szenario, das auf Ihrem Desktop lief, läuft nun in CI, einschließlich Pre Processors und Post Processors.
Ein ehrlicher Vorbehalt: Ein Skript, das auf etwas angewiesen ist, das nur auf Ihrer Maschine vorhanden ist, wie eine lokale Datei oder ein Paket, das Sie einmal geladen haben, kann in der Desktop-App funktionieren und dann in der CLI fehlschlagen, weil der Runner diese Abhängigkeit nicht hat. Beschränken Sie Skripte auf die gebündelten Bibliotheken oder $$.liveRequire(), damit sie überall gleich ausgeführt werden.
Häufig gestellte Fragen (FAQ)
Sind Apidog-Skripte mit meinen bestehenden Postman-Skripten kompatibel?
Meistens ja. Die Engine von Apidog verwendet dieselbe pm-Objekt-API, sodass pm.environment.set(), pm.response.json(), pm.test() und pm.expect() alle so funktionieren, wie Sie es kennen. Die beiden Unterschiede, die Sie beachten sollten, sind die Tab-Namen (Pre Processors und Post Processors statt Pre-request Script und Tests) sowie einige nicht unterstützte Aufrufe wie pm.nextRequest(). Die meisten Skripte können direkt eingefügt und ausgeführt werden.
Warum gibt pm.response in meinem Pre-Request-Skript „undefined“ zurück?
Weil es noch keine Antwort gibt. Pre Processors werden ausgeführt, bevor die Anfrage gesendet wird, daher ist noch nichts zur Überprüfung zurückgekommen. Jeder Code, der pm.response (dessen Status, Body, Header) liest, gehört in einen Post Processor. Wenn Sie im Pre-Stage einen Wert benötigen, rufen Sie ihn stattdessen von pm.request, einer Variablen oder einer Bibliothek ab.
Wie teile ich ein Skript über mehrere Anfragen hinweg?
Verwenden Sie Public Scripts unter Settings > Public Scripts. Schreiben Sie die Logik einmal, fügen Sie sie zum Tab Pre Processors oder Post Processors jeder Anfrage hinzu und denken Sie daran, dass öffentliche Skripte vor benutzerdefinierten Skripten in derselben Liste ausgeführt werden. Um eine Public Script-Funktion aus einem Custom Script aufzurufen, deklarieren Sie sie global, indem Sie sie ohne var, let oder const zuweisen.
Kann ich ein npm-Paket importieren, das Apidog nicht bündelt?
Ja, mit $$.liveRequire('package-name', (pkg) => { ... }), das das Paket zur Laufzeit herunterlädt und eine Internetverbindung benötigt. Für alles, was auf der integrierten Liste steht, wie crypto-js, moment oder uuid, verwenden Sie ein einfaches require(), ohne dass ein Netzwerk erforderlich ist. Beachten Sie, dass Sie nur ein ganzes Modul anfordern können, keinen Untermodulpfad.
Wo sehe ich, was mein Skript ausgegeben hat?
Verwenden Sie pm.console.log() oder console.log() und lesen Sie die Ausgabe in der Apidog-Konsole, nachdem Sie die Anfrage gesendet haben. Dies ist der schnellste Weg, um zu bestätigen, dass eine Signatur berechnet oder ein Token extrahiert wurde, bevor Sie es in einem Szenario verwenden.
Zusammenfassung
Pre Processors und Post Processors verwandeln eine statische Anfrage in eine, die sich selbst vorbereitet und ihre eigene Arbeit überprüft. Signieren Sie, bevor Sie senden, extrahieren und verifizieren Sie, nachdem Sie empfangen haben, und heben Sie gemeinsame Logik in Public Scripts, damit Sie sie nur einmal schreiben müssen. Die pm-API und die gebündelten Bibliotheken bedeuten, dass das meiste, was Sie von Postman kennen, direkt übernommen werden kann. Öffnen Sie Apidog, wählen Sie eine beliebige Anfrage und fügen Sie Ihr erstes Custom Script hinzu, um zu sehen, wie beide Phasen in einem einzigen Sendevorgang ablaufen. Der Einstieg ist kostenlos, keine Kreditkarte erforderlich.