In diesem Artikel zeigen wir dir, wie du mit Postman API Monitoring deine API Endpoints automatisiert überwachen kannst.
Intro
Das Bereitstellen von Rest API Endpoints gehört schon länger zum Standard vieler Software-as-a-Service (SaaS) Firmen. Gerade im B2B-Umfeld möchten viele Kunden eine Integration zwischen bestehenden Systemen und dem SaaS-Anbieter, um die Bereitstellung zu vereinfachen.
SaaS-Anbieter müssen deshalb dafür sorgen, dass die Rest API Endpoints einwandfrei funktionieren. Automatische Rests sind dabei unumgänglich. Postman bietet dabei die notwendigen Tools, um die eigenen Rest-API-Schnittstellen zu überwachen und beispielsweise ganze Workflows (Authentisierung, Erstellung, Änderung, Löschung) zu testen.
Account erstellen für Postman API Monitoring
Falls du noch keinen Postman Account besitzt, kannst du dich auf www.postman.com mit wenigen Mausklicks anmelden. Auch der kostenlosen “Free” Plan erlaubt dir, 1000 Monitoring API Calls pro Monat zu nutzen, somit 33 Calls pro Tag. Das reicht für kleinere Projekte.
Erstellen einer “Collection”
Eine Collection ist eine Gruppe von einem oder mehreren API Calls. Das Monitoring, das wir weiter unten in diesem Dokument erstellen, durchläuft automatisch diese Collection. Als Beispiel möchten wir ein Monitoring erstellen, welches im Xelon HQ den User Login, die Erstellung eines Linux-Servers, sowie die darauffolgende Löschung des Servers durchführt. Somit überwachen wir die gesamte Kette und würden informiert werden, wenn es an irgendeinem Punkt nicht weitergeht.
Dazu öffnen wir im Top Menu die Workspaces, und wählen unseren Workspace aus. Unter “Collections” klicken wir auf “New”.
Wähle nun “Collection”, um eine neue zu erstellen.
In der neuen Collection kannst du nun diverse Punkte übergreifend konfigurieren. Beispielsweise kannst du die Authentisierung definieren. Wichtig: Hinterlege in den Collections keine Usernamen/Passwörter oder persönliche Bearer Token, da diese Daten von jedem mit Zugriff auf die Collection genutzt werden. Falls du auf Collection Ebene die Authentisierung definieren willst, arbeite mit Variablen.
In unserem Fall verwenden wir Bearer Token für die Authentisierung. Als Variable verwenden wir “token”, was als “” im Feld definiert wird.
So haben wir global vorgegeben, dass die API Rests in dieser Collection Bearer als Authentisierung verwendet. Welcher Token verwendet wird, definieren wir dann weiter unten in den Environment Variablen.
Konfiguration der API Calls
Nun konfigurieren wir die notwendigen API Calls in der Collection. In unserem Fall sind es 4 Calls:
Linux-Server erstellen
- Linux Server erstellen
- Verifizierung, ob Server erfolgreich erstellt
- Server stoppen
- Server löschen
Um den ersten Request zu erstellen, klicken wir auf der Collection auf die drei Punkte, und im Menu auf “Add Request
Gib dem Call einen Namen, und definiere den Endpoint. In unserem Fall nutzen wir eine Post Requests, mit diversen Parameter, um den Linux Server zu erstellen.
Die Authorisierung belassen wir au “Inherit auth from parent”, um die Collection Authorisierung zu verwenden. Bei Bedarf kann hier auch eine separate Authentisierung genutzt werden.
Zusätzlich notwendige API Calls werden auf dieselbe Weise erstellt, in unserem Fall für die Verifizierung, den Stopp Befehl, sowie den Lösch-Befehl.
API Response Tests
Im Tab “Tests” kann definiert werden, ob der API Return auf gewisse Werte überprüft werden soll. Es ist auch möglich, Return Values in Variablen zu speichern, um diese dann im nächsten API Call zu verwenden. Mehr dazu in diesem Artikel.
Timeout mittels Pre-Request Script
Pre-Request scripts können beispielsweise genutzt werden, um Timeout/Delays zu definieren, bevor der Request ausgeführt wird. Standardmässig führt Postman den nächsten Request umgehend aus, sobald der vorgehende abgeschlossen ist. Dies kann zu Problemen führen, wenn der vorherige Request auf dem Backend Server einen Task triggert, der einige Sekunden oder vielleicht sogar Minuten benötigt, und der nächste Call auf einen abgeschlossenen Task angewiesen ist.
Folgender Code im Pre-request Script Tab verzögert die Ausführung um 120’000 Milisekunden, also 120 Sekunden:
setTimeout(function(){}, 120000);
Erstellung eines “Environment”
Im “Environment” werden Variablen definiert. Öffne die “Environments” links im Menü, und erstelle über “New” ein neues Environment.
In der Collection oben haben wir für die Authentisierung eine Variable mit dem Namen “TOKEN” erstellt. Diese Variable definieren wir nun im Environment.
Im Environment können natürlich noch weitere Variablen verwendet werden, die innerhalb der Collection zur Anwendung kommen.
Einrichten des Postman API Monitorings
Nun da wir die Collection und das Environment definiert haben, können wir unser Monitoring einrichten. Öffne dazu im Menu links die “Montitors”, klicke auf “New”, und wähle “Monitor”.
Klick auf “Monitor existing collection”, da wir diese bereits erstellt haben und wähle die soeben erstellte Collection aus.
Wähle einen Namen, das erstellte Environment, die Frequenz des Tests sowie die Notification Email.
Überwachung
Nach dem erfolgreichen Einrichten prüft Postman die Collection gemäss Konfiguration und Frequenz. In unserem Fall prüfen wir die Collection jede Stunde. Im Reporting sehen wir nun die Resultate.
Bei Problemen ist auch exakt ersichtlich, bei welchem Request das Problem aufgetreten ist.
Fazit zum Postman API Monitoring
Postman bietet eine einfache und schnelle Möglichkeit, die API Calls regelmässig auf deren Funktionen zu prüfen. Daneben bietet Postman noch eine Menge anderer Hilfsmittel. Mehr Infos dazu in unserer Knowledge Base oder natürlich auf www.postman.com.
What are your Feelings:
Feel free to Share this Article:
Xelon AG Poststrasse 15, 6300 Zug Switzerland
Leave a Reply
Your email address will not be published. Required fields are marked *