Postman ist das Photoshop unter den Testing-Tools: Es beherrscht mehr, als die meisten Anwender brauchen. Es wirkt unübersichtlich aufgrund der Vielzahl an Funktionen. Und es ist verdammt gut, wenn man sich wirklich damit auskennt. In diesem Beitrag gehe ich darauf ein, warum ich Postman täglich einsetze und in welchen Fällen ich auf Alternativen ausweiche.
API-Clients im Vergleich: Postman & Insomnia
Postman und Insomnia sind API-Clients, mit denen Du HTTP-Requests absenden kannst. Dabei ist Insomnia ein schlankes Tool, das mit einer übersichtlichen und intuitiven GUI überzeugt. Der Funktionsumfang ist dafür recht gering. Postman hingegen ist eine gewachsene Anwendung, die mehr kann, doch auf Grund der vielen Funktionalitäten auch unübersichtlicher ist.
Vorzüge von Postman: Postman-Sandbox, automatisierte Tests und Collection-Runner
Postman bringt eine Sandbox mit, in der Du JavaScript-Code ausführen kannst. So lassen sich Requests vorbereiten und Tests nach dem Absenden ausführen. Was damit alles möglich ist, lässt mein vorheriger Beitrag zum Thema automatisches Erneuern des Access Tokens erahnen. In Insomnia gibt es derartiges nicht.
Außerdem bietet Postman sogenannte Collection-Runner, in denen sich ausgewählte Requests der Reihe nach ausführen lassen. Auf dem Collection-Level kannst Du zudem Skripte schreiben, die Postman vor jedem einzelnen Request ausführt. Um mehrere Requests in Reihe laufen zu lassen oder aber um einen Request mehrmals hintereinander abzusenden, braucht Insomnia Plug-ins. Das mir bekannten Plug-in erledigt diese Aufgabe nur mäßig, da es lediglich alle Requests innerhalb eines Ordners der Reihe nach ausführt. Dadurch muss ein Request mehrfach dupliziert werden, um ihn in unterschiedlichen Szenarien einzusetzen.
Neben den zuvor genannten Punkten bietet Postman viele weitere Features, die ich derzeit nicht verwende. Zu nennen wären zum Beispiel Mock Server und Request Flows. Auch können Postman Workspaces in einer Cloud erstellt und zur Zusammenarbeit mit dem Team geteilt werden.
Vorzüge von Insomnia: Request-Chaining, Auto-Save und eine aufgeräumte GUI
Insomnia verzichtet auf die Tab-Ansicht zuletzt geöffneter Requests, arbeitet mit einer einfachen Ordner-Struktur und wirkt insgesamt aufgeräumter. Auch bietet Insomnia Auto-Save, wodurch Änderungen an Requests nicht verloren gehen. In Postman musst Du Deinen Request manuell abspeichern, bevor Du einen Tab schließt. Ansonsten verwirfst Du alle Änderungen.
Alleine aus diesen Gründen ist das Tool die bessere Wahl, wenn es nur darum geht, gelegentlich HTTP-Requests abzuschicken, um beispielsweise während der Entwicklung neue Endpunkte auszuprobieren. Zudem punktet Insomnia mit dem Feature verketteter Requests.
Request-Chaining in Insomnia
Requests lassen sich verketten, d. h. innerhalb der URL, des Body oder eines Header-Attributes lassen sich Platzhalter setzen, die durch die Werte einer Response eines anderen Requests ersetzt werden.
Ein einfaches Beispiel: Ein POST-Endpunkt erzeugt einen Teilnehmer mit Name und Id. Er gibt die Id in der Response zurück. Möchtest Du den dazugehörigen GET-Endpunkt testen, der den Teilnehmer mit der Id aufruft, kannst Du in der URL bspw. https://mein-service.com/teilnehmer/{{response=>body.attribute}} verwenden. So wird für den GET-Request die Id aus der letzten Response Deines POST-Requests eingesetzt.
Postman und Insomnia im Einsatz: so verwende ich beide Tools im gleichen Projekt
Es mag redundant wirken, doch derzeit verwende ich sowohl Insomnia als auch Postman im gleichen Projekt.
Postman nutze ich vor allem, um Use Cases durch verkettete Requests abzubilden. Mit der Test-Funktion von Postman führe ich so automatisierte Regressions-Tests durch. Dabei spare ich mir die Zeit, die Requests manuell zu verändern, da ich Pre-Request-Scripts erstellt habe, die vor jedem Request passende Testdaten erzeugen.
Außerdem nutze ich Postman, um Testdaten für manuelle Tests vorzubereiten. In meinem Projekt benötige ich oft Neuaufträge (Bestellungen in einem E-Commerce-Projekt), die ich anschließend unterschiedlich prozessiere. Mit einem Collection-Runner erzeuge ich dann gleich ein ganzes Set von Aufträgen, das ich anschließend nutze, um meine manuellen Tests auszuführen.
Insomnia hingegen setze ich ein, um die manuellen Tests auszuführen. Das hat mehrere Gründe: Einerseits ist es mir bei Postman schon zu oft passiert, dass ich Tabs geschlossen habe, ohne zu speichern. Die Änderungen an meinem Request waren damit verloren und ich musste entsprechende Anpassungen wiederholen. Andererseits ist Insomnia insgesamt übersichtlicher Aufgebaut, weshalb mal eben einen neuen Request hinzuzufügen oder einen anderen Request zu duplizieren schneller geht.
Ein wesentlicher Grund aber sind die verketteten Requests. Mit ergänzenden Skripten und zwischengespeicherten Umgebungsvariablen lässt sich dieses Verhalten auch in Postman nachbilden, doch ist es in Insomnia mit der nativen Funktion besser gelöst.
Fazit
Abschließend möchte ich anmerken, dass ich im Projekt zunächst nur Insomnia eingesetzt habe. Für die automatisierten Regressionstests habe ich später Postman eingeführt und bin so bei dem aktuellen Workflow gelandet. Wenn ich meine Collection von Beginn an in Postman gepflegt hätte, würde ich vermutlich ausschließlich Postman verwenden. Gleichzeitig würde ich ausschließlich mit Insomnia arbeiten, wenn ich ausschließlich einen Client bräuchte, um manuell HTTP-Requests abzuschicken.
Schreibe einen Kommentar