Postman

Postman ist ein weit verbreitetes Tool, das Entwicklern hilft, APIs zu testen, zu entwickeln und zu dokumentieren. Es bietet eine benutzerfreundliche Oberfläche, um HTTP-Anfragen zu erstellen und zu senden. Außerdem ermöglicht Postman die Zusammenarbeit von Teams an API-Projekten und bietet Funktionen wie Team-Workspaces, um gemeinsam an APIs zu arbeiten. Als zentrale Anlaufstelle für API-Dokumentation kann Postman genutzt werden, um einen Überblick zu bekommen und ist daher vor allem auch für Onboarding von neuem Personal praktisch.

Neben HTTP kann Postman auch als Klient für GraphQL, Protobuf/GRPC, Websockets und MQTT-Endpunkten genutzt werden. Das Frontend kann als Standalone-Anwendung, aber auch direkt im Browser genutzt werden.

Interaktion mit Schnittstellen

Grundsätzlich ist Postman sehr analog zu einem HTTP-Service aufgebaut: links im UI ist eine Baumstruktur, welche „Collections“ auflistet, die sich ausklappen lassen, um weitere Einträge und Ordner anzeigen zu lassen. Eine Collection bildet i.d.R. genau einen HTTP-Service ab. Die ausklappbaren Einträge sind Endpunkte des Service (z.B. POST /login) und die Ordner komplexere Pfade (z.B. POST /cart/add). Collections und Endpunkte können jeweils mit Dokumentation versehen werden. Pro Endpunkt können neben der HTTP-Methode und dem Pfad weitere Informationen vorbefüllt und als Beispiel gespeichert werden. Dazu gehört:

• Request Body
• Request Header
• URL-Parameter
• Pre-Request Script
• Post-Response Script
• Beispiel HTTP-Response Body

Pro Endpunkt können mehrere solcher Beispiele gespeichert werden. In der Regel ist es sinnvoll, pro Endpunkt ein positives (Statuscode 2xx) und ein negatives (Statuscode z.B. 4xx) zu speichern. Die Collections und Endpunkte können zwar per Hand einzeln angelegt werden, i.d.R. werden diese aber automatisch angelegt auf Grundlage von etwa einer OpenAPI-Spezifikation. Neben dem OpenAPI-Import unterstützt Postman weitere Formate:

• RAML
• Protobuf
• GraphQL
• WSDL

Pre-Request Scripts werden ausgeführt, bevor die HTTP-Anfrage gesendet wird und können beispielsweise genutzt werden, um den Request Body mit generierten Daten oder mit verarbeiteten Daten einer anderen Anfrage vorzubefüllen. Post-Request Scripts werden nach Erhalt der HTTP-Antwort ausgeführt und haben auf diese Zugriff. Collections können Variablen haben, um Daten zwischen Anfragen zu speichern und wiederzuverwenden. Post-Request Scripts können z.B. genutzt werden, um Daten aus der Antwort in einer solchen Variable zu speichern. Ganz konkret kann ein Session-Token aus einer Login-Antwort gespeichert und für weitere Anfragen, welche Authentifikation benötigen, genutzt werden. Post-Response Scripts werden außerdem für Unit Testing genutzt.

Unit Testing

Neben dem manuellen Ausführen und Validieren von Endpunkten können Endpunkte auch automatisiert getestet werden. Dazu wird dem Nutzer in dem Post-Response-Script eine JavaScript-Schnittstelle bereitgestellt, mithilfe deren Unit-Tests definiert werden können. Die Tests werden nach jedem Aufruf des Endpunktes ausgeführt und die einzelnen Ergebnisse aufgelistet.

Neben der grafischen Anwendung kann Postman auch als CLI-Tool genutzt werden. Dies ist vor allem nützlich, um Unit-Tests einer Collection in einer CI/CD-Pipeline auszuführen, etwa nachdem der Service automatisiert in einer Testumgebung aufgesetzt wurde. Alle Tests einer Collection können gebündelt als JSON-Datei exportiert und von der CLI genutzt werden

Mockserver

Neben der Dokumentation von bestehenden Services kann Postman direkt im Entwicklungsprozess einer Schnittstelle genutzt werden. Bevor der Service vollständig entwickelt wurde, kann die Schnittstelle in Postman angelegt und mit Beispielen dokumentiert werden. Alle Beispiele einer Collection können dann genutzt werden, um einen Mockserver zu erstellen. Dabei antwortet der Mockserver auf eine Anfrage mit einem passenden Beispiel aus der Collection. Zum Auswählen eines Beispiels wird grundsätzlich Pfad und Methode genutzt, dies kann aber auch noch auf Antwortkörper und bestimmte Header erweitert werden. Der Mockserver wird direkt von Postman selbst gehostet und kann ohne Weiteres über das Internet benutzt werden. Mockserver können genutzt werden, um eine Schnittstelle zu benutzen, bevor der dazugehörige Service implementiert ist, um die Entwicklung zu optimieren und um auf Fehler der Schnittstelle frühzeitig aufmerksam zu werden. Ganz konkret kann in einer Anwendung, die aus HTTP-Server und Web-Frontend besteht, das Frontend parallel zu dem Server implementiert werden, indem ein Mockserver genutzt wird.

Flows

Flows ermöglichen die Automatisierung von Abläufen und bieten eine benutzerfreundliche visuelle Programmierung, bei der Blöcke miteinander verknüpft werden. Eine Vielzahl von Standardoperationen ist direkt verfügbar, sodass gängige Aufgaben schnell umgesetzt werden können. Das Verhalten der Flows lässt sich jedoch durch TypeScript beliebig erweitern, wodurch eine hohe Flexibilität erreicht wird. Flows können zudem auf andere Flows zurückgreifen, was die Modularität und Wiederverwendbarkeit von Abläufen fördert. Zusätzlich bietet ein großer Katalog von Beispielabläufen eine wertvolle Grundlage, um schnell in die Automatisierung einzutauchen und bewährte Lösungen zu nutzen.

Alternativen

Hoppscotch

Ein Nachteil von Postman ist, dass das Backend nicht self-hosted werden kann und somit der gesamte Workspace in der Postman-Cloud gespeichert wird. Eine Alternative, welche dies ermöglicht, ist Hoppscotch. Hoppscotch ist Open Source und bietet eine Nutzeroberfläche, die sehr ähnlich zu Postman ist:

Hoppscotch unterstützt neben REST, GraphQL, Protobuf/GRPC, MQTT und Websockets auch direkte Integration mit der weit verbreiteten Websocket-Bibliothek „Socket.io“. Als CLI kann Hoppscotch etwa auch in CI/CD-Pipelines genutzt werden, um Schnittstellen vor dem Deployment automatisiert zu testen.

Insomnia

Eine weitere Alternative zu Postman ist Insomnia. Wie auch Hoppscotch ist Insomnia Open Source und von der Nutzeroberfläche her recht ähnlich zu Postman:

Wichtige Features von Insomnia sind:

• Debugging
• Design mit OpenAPI-Editor
• Unittesting
• Mockserver (kann auch self-hosted werden)
• Nutzung in CI/CD durch Insomnia-CLI
• Erweiterbarkeit durch Plug-in-System

Neben dem Self-Hosting des Insomnia-Backends oder der Cloud können alle Daten auch komplett lokal gespeichert oder per Git-Integration synchronisiert werden.