Von Postman zu Paw
Mark Schmeiser
Wir arbeiten jeden Tag mit Schnittstellen zu eigenen oder fremden Diensten. Diese s.g. APIs müssen verwaltet werden. Neben der Dokumentation der APIs benutzen wir deshalb Tools, um Schnittstellen zu testen oder um Funktionen anzusprechen, für die es keine Benutzeroberflächen gibt.
Lange Zeit haben wir dafür Postman benutzt. In den vergangenen Monaten fehlten uns aber immer wieder Funktionen, oder die vorhandenen Funktionen arbeiteten nicht so, wie wir uns das gewünscht haben.
Deshalb haben wir uns auf die Suche nach Alternativen zu Postman gemacht und sind auf die Mac OS App „Paw“ gestoßen. Paw ist eng verzahnt mit RapidApi und die neuste Programmversion hat ihren Namen bereits zu RapidApi geändert. Dennoch findet man das Tool im Netz immer noch eher unter dem Namen „Paw“.
Kosten
Ein Grund für unseren Wechsel waren die Kosten. Während wir bei Postman für ein Teammitglied zwischen 12€ und 15€ zahlen müssen (je nach Zahlungsfrequenz), können wir Paw im Team ohne Mehrkosten nutzen.
Man muss dazu sagen, dass wir mit SetApp ein hervorragendes Abo-System haben. Wir zahlen pro Monat eine Abo-Gebühr für SetApp und können darüber auf zahlreiche Apps zugreifen, für die sonst separate Kosten anfallen würden. Paw ist in diesem Abo ebenfalls enthalten.
Wäre das nicht der Fall, wäre die Team-Funktion ab sechs Benutzern mit zehn Euro pro Benutzer aber immer noch günstiger als das Postman-Abo.
Funktionen
Eine Funktion, die uns zum Wechsel bewogen hat, war die Definition von Variablen wie URLs, oder Benutzernamen und Passwörter/Tokens. Diese lassen sich zwar auch in Postman anlegen, allerdings nicht gruppieren. Paw bietet uns diese Möglichkeit. Somit stehen diese Variablen auch nur in den Umgebungen zur Verfügung, für die sie festgelegt wurden.
Bei Postman war das nicht der Fall und wir konnten überall auf Variablen zugreifen, die nur für eine API oder sogar ausnahmslos für eine bestimmte Entwicklungsumgebung einer API relevant waren.
Bei Paw können wir nun also unsere Variablen für die Testumgebung von API A festlegen, ohne dass diese Variablen auch bei API B zur Auswahl stehen.
Wo wir schon bei Umgebungen sind: Bei Paw ist es uns möglich, schnell zwischen Umgebungen zu wechseln. Beim Wechsel der Umgebung werden die Inhalte der Variablen entsprechend ausgetauscht. Nutzen wir in einem API-Request statt einer festen URL als eine URL-Variable, brauchen wir nur zwischen Test- und Live-Umgebung zu wechseln und die URL im Request zeigt automatisch auf die richtige Schnittstelle.
Ein weiterer Vorteil: Die enthaltene Synchronisation beinhaltet die Variablen, sodass alle Teammitglieder sie im Zugriff haben. Hier gilt es dann natürlich darauf zu achten, keine sensiblen Daten zu hinterlegen.
Synchronisation
Wo wir schon beim Thema sind: Damit alle Teammitglieder Zugriff auf die erstellten Requests und Variablen haben, werden die Daten synchronisiert. Das läuft über Git. So können verschiedene Personen an den Requests arbeiten, ohne sich großartig in die Quere zu kommen. Das Anlegen und Mergen von Branches ist ebenfalls möglich.
Beim Arbeiten mit dem System kam es dann anfangs leider doch zu Problemen, die sich mit mehr automatisch auflösen ließen und dann vorsichtig händisch aufgelöst werden mussten.
Das war an sich kein großes Problem, kostet aber u.U. unnötig Zeit.
Fazit
Auch wenn die UI nicht ganz so aufgeräumt ist, wie bei Postman, überzeugt uns der Funktionsumfang und die vielen praktischen Features bei Paw.
Abgesehen von ein paar kleinen Mankos, wie Probleme beim Synchronisieren oder dass JSON-Ausgaben immer erst als Tabelle angezeigt werden und man auf JSON-Text umstellen muss, sind wir im Alltag sehr zufrieden mit Paw.
Wer nach einer Alternative zu Postman sucht, sollte sich Paw auf jeden Fall einmal ansehen.
Natürlich gibt es noch andere Tools da draußen, die infrage kämen. Welche habt ihr im Einsatz? Oder seid ihr gerade selbst auf der Suche? Wir freuen uns über Kommentare.