API-Clients – Alternativen zu Postman

API-Clients spielen eine ganz wesentliche Rolle bei unserer täglichen Arbeit. Sie helfen uns dabei, APIs zu testen, zu debuggen oder auch ganz einfach zu verwenden. Für viele Jahre war Postman dabei das Maß aller Dinge, das Tool der Wahl.

Genau genommen stellte sich die Frage, welchen Client wir bei der API-Arbeit nutzen würden, gar nicht. Postman war einfach allgegenwärtig und wurde von allen genutzt, egal wohin man schaute.

Ab Mai dieses Jahres änderte sich das allerdings erheblich: Postman kündigte in einem Blog-Post an, dass es einen neuen „leichtgewichtigen API-Client“ geben würde (und in diesem Zug das „Scratchpad“ abgeschafft werden würde). Zunächst war diese Ankündigung nicht weiter relevant, da es erst einmal nur um die Deprecation ging. Problematischer wurde es, als die Postman-App nach Neuinstallationen die Funktion schon nicht mehr enthielt, die ab September auch für Bestandsinstallationen entfernt werden sollte.

Früher oder später würden wir also nach Alternativen schauen müssen.

Doch gehen wir noch einmal einen Schritt zurück: Was ist das Problem mit dem neuen leichtgewichtigen API-Client oder Postman insgesamt?

Postman’s Entwicklung als Problem

Schon seit Längerem hat Postman sich von einem bloßen API-Client zu einer API-Plattform entwickelt, die viele verschiedene Funktionen bietet. Immer stärker ins Zentrum rückten dabei Synchronisierung und Kollaboration. Ohne Zweifel bieten sich dadurch viele Vorteile und tolle Möglichkeiten — wenn man sie denn nutzen kann beziehungsweise darf.

Doch genau hier liegt das Problem: Wir arbeiten mit und an den APIs unserer Kunden. Da können wir nicht einfach alle Daten in die Cloud hochladen und dort speichern, sofern die dabei verwendeten Tools nicht explizit freigegeben sind.

Das ist beispielsweise bei Postman nicht der Fall. Alle Daten müssen also zwingend lokal gespeichert werden und können nur über Git-Repositories ausgetauscht werden, gegebenenfalls verschlüsselt.

Bisherige Lösung

Bisher konnten wir Postman ohne Probleme nutzen, da wir die Cloud-Funktionalitäten schlicht nicht verwendet haben. Dafür musste lediglich auf das Anlegen eines User Accounts verzichtet werden. Dadurch konnte nichts mit der Cloud synchronisiert werden und alle Daten wurden lokal gespeichert. Für den Austausch im Team haben wir Collections und Environments manuell exportiert, in Git-Repositories abgelegt und von dort wieder importiert.

Das war zwar nicht besonders komfortabel, aber es funktionierte lange Zeit ohne Komplikationen. Die separat abgelegten Environment-Dateien boten dabei außerdem die Möglichkeit, Passwörter und ähnliche sensitive Informationen nur verschlüsselt auszutauschen. Da wir dabei außerhalb von Postman auf Datei-Ebene arbeiteten, hatten wir alle Möglichkeiten: Manche setzen auf SOPS, andere nutzten stattdessen git-crypt.

Der für die Verschlüsselung von einzelnen Dateien gewählte Weg hat dabei keinerlei Auswirkungen auf die Arbeit mit Postman selbst, weshalb ich hier nicht weiter darauf eingehen möchte.

Postman Lightweight API Client als Nicht-Alternative

Die Einführung des neuen „leichtgewichtigen API-Clients“ als offizieller Ersatz des Scratchpads hat Postman perspektivisch für uns ins Aus katapultiert und unbrauchbar gemacht.

Da es sich bei dem groß angepriesenen neuen Client wirklich nur um einen Client handelt, fehlen nahezu alle elementaren Funktionalitäten, die wir bei unserer Arbeit unbedingt benötigen, allen voran die Möglichkeit, (strukturierte) Collections mit API-Requests anzulegen und dabei verwendete Parameter und Variablen in Environments zu verwalten.

All das bietet der neue Client nicht, im Prinzip handelt es sich um eine grafische Alternative zu curl.

Natürlich sind die Funktionen nicht weg. Die Neuerung ist, dass man eingeloggt sein muss, um sie verwenden zu können — und sobald man sich einloggt, werden alle Daten in die Cloud hochgeladen und dort gespeichert. Ohne Ausnahme, ohne Nachfrage, ohne Möglichkeit, das zu verhindern. Ein absolutes No-go!

Deaktivieren automatischer Updates in Postman oder die Installation älterer Versionen schaffen nur bedingt Abhilfe. Auf der einen Seite wollen wir nicht ewig eine potenziell veraltete Software-Version einsetzen, auf der anderen Seite hat Postman in mehreren Fällen auch die Einstellungen zum automatischen Software-Update ignoriert und uns trotzdem die neue Version untergejubelt und freudestrahlend mit den unliebsamen Neuerungen begrüßt.

Wenn überhaupt, haben wir also nur Zeit für die Suche nach Alternativen gewonnen.

In dieser Zeit hat sich auch gezeigt, dass vonseiten Postmans kein Interesse an Offline-Funktionalitäten besteht. Dahingehende Anfragen werden entweder ignoriert oder abschlägig beantwortet. Inzwischen wurden sogar alte Versionen entfernt, so dass sie nicht mehr installiert werden können.

Eine Alternative musste gefunden werden!

Anwendungsfälle und Anforderungen

Für die Suche nach einer Alternative haben wir uns zunächst überlegt, welche Anwendungsfälle wir mit Postman abdecken und welche Anforderungen wir an einen API-Client stellen.

Kontext

Das Tool, das wir suchen, muss im Kontext eines Beratungsunternehmens eingesetzt werden können. Das bedeutet, die Teams auf beiden Seiten, beim Kunden und bei uns, müssen damit arbeiten können.

Sensitive Informationen müssen angemessen behandelt werden können, um keine Vertraulichkeitsvereinbarungen zu verletzen. Insbesondere bedeutet das, dass keinerlei Daten in die Cloud hochgeladen werden dürfen.

Stattdessen muss es möglich sein, Daten lokal zu speichern beziehungsweise zu exportieren und zu importieren, um das Teilen im Team zu ermöglichen. Besonders vorteilhaft wäre es, Postman-Collections und -Environments importieren zu können, um die Migration zu erleichtern.

Weiterhin folgt aus dem Einsatzkontext, dass der API-Client, den wir suchen, für alle gängigen Betriebssysteme verfügbar sein muss, also macOS, Linux und auch Windows.

Übrigens liegt der Hauptfokus auf HTTP-Web-APIs (REST APIs). GraphQL, gRPC und Ähnliches sind nicht Gegenstand der Suche, obwohl es natürlich schön wäre, Unterstützung dafür zu haben.

Funktionen

Die folgende Liste von Funktionen ist nicht erschöpfend, sollte aber eine grobe Vorstellung davon geben, wonach wir gesucht haben:

• Wir müssen in der Lage sein, API-Anfragen in Sammlungen zu organisieren, idealerweise sogar in Projekten/Arbeitsbereichen.
• Sammlungen müssen Ordner unterstützen, auch verschachtelt, damit wir unsere APIs, Tests oder Maintenance-Workflows etc. basierend auf Systemen, Kategorien usw. organisieren können.
• Es müssen mehrere Environments (begrenzt auf den Arbeitsbereich/das Projekt) vorhanden sein, wie DEV, Staging und Production. Environments auf Sammlungs- und Ordner-Ebene sind nice-to-have, jedoch nicht zwingend erforderlich.
• Als Authentifizierungsmechanismen müssen HTTP Basic Authentication, API Key, OAuth 2.0 mit Client Credentials Flow und Authorization Code Flow sowie die Authentifizierung mit Client-Zertifikaten unterstützt werden.
• Auf irgendeine Weise muss es möglich sein, Request-Parameter basierend auf der Antwort eines vorangegangenen Requests zu setzen (pre-request scripts).
• Header-, Pfad- und Query-Parameter sollten als „echte“ Parameter gesetzt werden können, also ohne Umweg über Variablen aus der Environment. Wenn es zum Beispiel eine Anfrage gibt, um einen User anhand einer ID abzurufen, sollte es möglich sein, etwas wie GET /users/{userId} zu nutzen, wobei der Wert von userId für das Request festgelegt wird, anstatt es als GET /users/a2b8ef58-ae0a-474a-84da-dc156bcce6b8 hinzufügen zu müssen.

Eine Kommandozeilenintegration für die automatisierte Ausführung von Requests (und Tests), beispielsweise für die CI/CD-Integration, wie mit Newman oder Postman CLI, ist ein Plus-Punkt, steht aber nicht im Vordergrund.

Der Fokus bei unserer Suche nach alternativen API-Clients lag auf der manuellen Arbeit mit APIs, nicht auf der Automatisierung.

Alternative API-Clients

Nach intensiver Suche und Ausprobieren verschiedenster API-Clients kann ich die folgenden Tools empfehlen:

• Insomnia
• Insomnium
• Kreya
• Testfully
• Bruno

Nicht alle erfüllen alle Anforderungen vollständig oder auf die gleiche Weise, aber sie sind alle in der Lage, die meisten unserer Anwendungsfälle abzudecken. Zum Teil machen sie dabei sogar einen besseren Eindruck als Postman.

Insomnia vs. Insomnium

Bevor wir einen genaueren Blick auf die einzelnen Tools werfen, muss ich ein paar allgemeine Worte mehr zu Insomnia und Insomnium verlieren, die für die Einordnung der beiden Tools und Betrachtung als Alternativen zu Postman wichtig sind.

Insomnia existiert schon seit einigen Jahren und wurde 2019 von Kong übernommen. Es handelt sich um ein Open-Source-Projekt, das unter der MIT-Lizenz veröffentlicht wird.

Über die Jahre hat sich Insomnia zu einem sehr mächtigen API-Client entwickelt, der einige Funktionen bietet, die Postman nicht hat.

Nur wenige Tage nachdem Postman das Scratchpad abgeschafft hatte, verärgerte Kong die Insomnia-Community jedoch massiv und stieß sie regelrecht vor den Kopf: Mit der Einführung von Insomnia 8 hielt praktisch über Nacht eine faktische Account-Pflicht und Cloud-Synchronisierung Einzug in Insomnia — genau wie bei Postman zuvor.

Zwar kann Insomnia auch ohne User Account noch weiter verwendet werden, ist dann jedoch auf ein Projekt beschränkt. In der alltäglichen Arbeit ist das eine massive Einschränkung, die Insomnia von der vielleicht idealen Alternative zur Notlösung werden ließ.

Nahezu unmittelbar nach dieser erheblichen Änderung von Insomnia wurde Insomnium als Fork ins Leben gerufen. Gestartet auf dem Stand der letzten Insomnia-Version ohne „Cloud- und Account-Pflicht“ hat sich das Projekt vollständiger Offline-Funktionalität verschrieben und sich darüber hinaus zum Ziel gesetzt, wesentliche Aspekte zu überarbeiten oder neu zu schreiben.

Ein Merge zurück zu Insomnia ist nicht vorgesehen. Zwar liegen die beiden Projekte noch nicht weit auseinander, aber der federführende Entwickler von Insomnium hat sich bewusst dafür entschieden, einen eigenen Weg zu gehen.

Überblick

Die folgende Tabelle gibt einen Überblick über die wichtigsten Funktionen und deren Unterstützung in den jeweiligen API-Clients, die wir uns angesehen haben.

Die verwendeten Zeichen haben dabei die folgende Bedeutung:

• ✅: Unterstützt
• ❌: Nicht unterstützt
• 💰: Nur in einer Bezahlversion verfügbar
• (✅): Unterstützt, aber nur mit Einschränkungen bzw. über zusätzliche Plugins
• (❌): Nicht unterstützt, aber über alternative Wege annähernd möglich

Es wird deutlich, dass es den perfekten API-Client (der nicht automatisch sämtliche Daten in die Cloud synchronisiert) derzeit nicht zu geben scheint.

Highlights

Die betrachteten Clients setzen unterschiedliche Schwerpunkte, die zum Teil Alleinstellungsmerkmale mit sich bringen. Liegt der Fokus der eigenen Arbeit auf diesen Bereichen, kann das die Entscheidung für einen bestimmten Client maßgeblich beeinflussen.

Insomnia und Insomnium

Insomnia und Insomnium stechen beispielsweise durch besonders viele Import-Möglichkeiten hervor (neben den in der Tabelle aufgeführten Formaten bieten die Tools noch weitere Import-Optionen). Damit kommen die beiden Tools in einer Vielzahl von Szenarien als Migrationsoption infrage.

Darüber hinaus kann die Funktionalität des Clients durch Plugins flexibel erweitert werden, entweder aus der offiziellen Plugin-Sammlung oder durch eigene Plugins.

Das ursprüngliche Projekt und der Fork unterscheiden sich derzeit vor allem in der Unterstützung von Cloud- und Team-Funktionalitäten in Insomnia, die in Insomnium entfernt worden sind. Insomnia lässt Nutzende in der aktuellen Version wählen, ob Projekte synchronisiert werden sollen/können oder ob sie lokal gespeichert werden sollen.
Dafür ist allerdings ein User-Account erforderlich, was für die Auswahl der hier betrachteten Tools ursprünglich ein Ausschlusskriterium war. Insomnia ist vor allem in der Auswahl, da es unsere initiale, abgestimmte Postman-Alternative war, wir die Migration bereits abgeschlossen hatten und mit der aktuellen Version die Cloud-Synchronisierung nicht mehr verpflichtend ist, wir das Tool also weiter einsetzen können.

Insomnium bietet nichts dergleichen, lediglich eine eingebaute Git-Integration ist für den Austausch von Daten vorgesehen. Stattdessen liegt ein Fokus der weiteren Entwicklung auf Stabilität und Performance.

Es ist nicht vorgesehen, dass Insomnium zu Insomnia zurückgeführt wird. Beide Projekte sollen eigenständig weitergeführt werden.

Kreya

‍Kreya bietet eine einzigartige Option für die Arbeit mit API-Spezifikationen: Der Import ist nicht nur der Startpunkt für das Anlegen einer Collection, sondern das Projekt wird fortwährend mit der Spezifikation synchronisiert. Darüber hinaus wird die Authentifizierung global konfiguriert und muss nicht für jeden Request einzeln gesetzt werden, sondern wird nur referenziert. Damit eignet Kreya sich besonders gut für neue Projekte, die auf einer API-Spezifikation basieren und keiner Migration von einem anderen Tool bedürfen.

Testfully

Testfully ist stark auf das Testen von APIs ausgelegt. Das heißt, genau genommen enthalten die Collections in Testfully keine API-Requests, sondern Tests, die aus mehreren Schritten bzw. Requests bestehen. Konfigurationsmöglichkeiten der Ausführung der Collections erstrecken sich dabei auf verschiedene Variablen-Sets und in unterschiedlicher Reihenfolge, einschließlich paralleler Ausführung der Requests.

Bruno

Bruno erhebt den Anspruch ein revolutionärer API-Client zu sein, der die lokale Speicherung von Daten an erste Stelle stellt. Außerdem werden Collections und Requests verzeichnis- und dateibasiert abgelegt, wobei Requests in einer eigenen Markup-Sprache beschrieben werden, die auch von Bruno CLI unterstützt wird.

Wodurch Bruno ansonsten besonders hervorsticht, ist die hohe Frequenz von Releases neuer Versionen, die die aller anderen hier betrachteten Tools deutlich übertrifft. Obwohl einige vielleicht wesentliche Funktionen derzeit (noch) nicht umgesetzt sind, stehen sie auf der Roadmap und sollen folgen. Auch so erfreut sich das Tool bereits einer großen Beliebtheit.

Unsere Alternative

Welchen API-Client verwendet man / verwenden wir denn nun?

Ich hatte es oben bereits angedeutet: Wir hatten uns bereits für Insomnia entschieden und auch einige unserer Kunden sind dieser Empfehlung gefolgt und den Weg mit uns gemeinsam gegangen. Die Migration von Postman zu Insomnia ging nicht ohne Probleme und Schmerzen vonstatten, das muss ehrlicherweise an dieser Stelle erwähnt werden. Einige Beispiele:

• Anfangs wurden Referenzen auf Environment-Variablen aus Postman nicht korrekt importiert und erforderten manuelle Nacharbeit in den Insomnia-Collections aufgrund unterschiedlicher Syntax.
• Einige Client-Zertifikate haben in Postman einwandfrei funktioniert, in Insomnia hingegen zunächst nicht.
• Für die Verwendung von Path Parametern gibt es in Insomnia nach wie vor keine native Unterstützung und wir mussten uns für eines von drei in Frage kommenden Plugins entscheiden.
• Pre- und Post-Request-Scripte mussten, soweit es eben möglich war, in Insomnia mit Request Chaining nachgebildet werden.

In der einen oder anderen Diskussion bei der Suche nach Postman-Alternativen war auch vom „geringsten Übel“ die Rede, wenn es um Insomnia ging. Schließlich sind wir jedoch bei einem weitestgehend funktionierenden Setup angekommen, das wir nun weiter verwenden können.

Entsprechend entsetzt und verärgert waren wir, als Kong buchstäblich über Nacht gravierende Änderungen eingeführt hatte. Die Suche nach Alternativen ging also von Neuem los.

Anders als Postman hat Kong jedoch auf den Aufschrei und die Kritik der Community reagiert und ist ihr so weit entgegen gekommen, dass Insomnia weiterhin eingesetzt werden kann, während parallel dazu sehr schnell Insomnium entstand.

Beide Tools befinden sich bei uns derzeit im Einsatz, was bisher auch kein Problem ist, da beide Tools mit dem gleichen Datenformat arbeiten und sich die Daten problemlos austauschen lassen.

Es soll auch nicht unerwähnt bleiben, dass wir Insomnium noch mit einem gesunden Maß an Skepsis oder Vorsicht beobachten, da es sich um ein sehr junges Projekt handelt und abzuwarten bleibt, wie nachhaltig es sich entwickelt.

Die anderen hier vorgestellten Tools mögen interessante Ansätze bieten, sind jedoch nicht weiter als für einen Überblick und diesen Vergleich betrachtet worden:

• Kreya bietet keine Möglichkeit zur Migration unserer Postman- bzw. Insomnia-Collections.
• Testfully ist für unsere primären Anwendungsfälle zu sehr auf das Testen von APIs ausgelegt oder lässt die Unterstützung von Client-Zertifikat-Authentifizierung vermissen, so dass es nicht in allen Projekten genutzt werden kann.
• Bruno kommt ohne die Unterstützung von OAuth-Authentifizierung für einen produktiven Einsatz in unseren Projekten nicht in Frage.

Fazit

Wir haben Veränderungen im Feld der API-Clients beleuchtet, insbesondere im Zusammenhang mit Postman, und die damit verbundenen Herausforderungen für Datenschutz und lokale Speicherung.

Wir haben verschiedene alternative API-Clients mit ihren unterstützten Funktionalitäten betrachtet, um sie mit konkreten Anwendungsfällen und Anforderungen abzugleichen. Für uns fiel die Entscheidung letztendlich auf Insomnia (und/oder Insomnium). Beide bieten den notwendigen Funktionsumfang und die Migration war bereits abgeschlossen, als die Welt der API-Clients erneut ins Wanken geriet.

Glücklicherweise hat Kong die kurzfristige Entscheidung korrigiert und mit Insomnium steht eine junge, derzeit voll kompatible Alternative zur Verfügung. Andere vorgestellte Tools werden aufgrund spezifischer Anforderungen oder der Macht des Faktischen, der bereits geschaffenen Tatsachen, nicht weiter in Betracht gezogen. Die weitere Entwicklung bleibt abzuwarten.

Insgesamt bietet der Artikel einen Überblick über vielversprechende Möglichkeiten in der API-Client-Landschaft und bietet Einblicke und Anregungen für diejenigen, die eine Alternative zu Postman suchen.