Da inzwischen alle REST-APIs bauen, brauchen auch alle eine Möglichkeit, an ihnen herumzustochern. Das sind die vier Clients, die mir in zehn Jahren Programmieren und Freelancing am häufigsten begegnet sind — was jeder wirklich gut kann und wo jeder dich nervt.
Die Reihenfolge ist keine Rangliste. Sie lösen unterschiedliche Probleme, und die interessante Frage ist, welches Problem du hast.
1. Swagger UI
Swagger UI fällt aus der Reihe, weil du es nicht installierst — es kommt mit der API. Zeig es auf eine OpenAPI-Spezifikation, und du bekommst eine durchblätterbare Seite mit jedem Endpunkt, jedem Parameter und einem "Try it out"-Button.
Was es wirklich gut kann: die Eingangstür sein. Eine neue Entwicklerin, ein Frontend-Team, ein externer Integrator — keiner von ihnen sollte dich um einen Postman-Export bitten müssen. Sie öffnen eine URL, und die ganze API ist da, dokumentiert und ausführbar.
Und wenn die Spezifikation aus Attributen im Controller erzeugt statt von Hand gepflegt wird, kann die Dokumentation nicht veralten. Das ist viel wert. Handgeschriebene API-Dokumentation ist an dem Tag korrekt, an dem sie geschrieben wird, und einen Monat später irreführend.
Wo es wehtut: Es ist ein Dokumentationswerkzeug mit einem Absenden-Button, keine Arbeitsumgebung. Keine gespeicherten Bodies für die zwölf Varianten, die du testest, kein Scripting, kein Verketten der Ausgabe eines Calls in den nächsten. Auth ist meistens ein Token, das du einfügst und beim Neuladen verlierst.
Nimm es für: eine API zu erkunden, die du noch nie gesehen hast, und dafür zu sorgen, dass niemand dich fragen muss, was deine API kann.
2. Postman
Das, was alle kennen. Eine komplette Arbeitsumgebung: Collections, Umgebungen, Scripting, Tests, Mock-Server, das ganze Programm.
Was es wirklich gut kann: alles, was kein einzelner Request ist. Umgebungen lassen dieselbe Collection per Dropdown gegen lokal, Staging und Produktion laufen. Skripte können sich einloggen, ein Token greifen und es als Variable setzen, sodass jeder folgende Request authentifiziert ist, ohne dass du etwas anfasst — das ordentlich einzurichten lohnt sich, es ist ein eigener Artikel.
Es ist außerdem das Einzige auf dieser Liste, das auch Nicht-Entwickler bedienen können. Wenn ein Projektmanager oder jemand aus der QA ein API-Problem reproduzieren muss, ist Postman die Antwort.
Wo es wehtut: Es will ein Cloud-Produkt sein. Anmeldung, Workspaces, Sync, und ein stetiges Abwandern von Funktionen hinter einen Team-Plan. Und Collections leben in Postmans Welt, nicht in deinem Repository, und so bekommst du am Ende von jedem Entwickler eine leicht abweichende private Kopie — genau das Problem, über das ich in wie du REST-Requests teilst geschrieben habe.
Nimm es für: gemischte Teams, komplexe Auth-Flows, alles, wo jemand ohne deine IDE einen Request schicken muss.
IDE-basierte Clients
Fast jede IDE bringt inzwischen einen REST-Client mit. Das kann einschränken, wenn nicht alle im Team dieselbe IDE nutzen, aber es ergibt trotzdem viel Sinn, das Testwerkzeug in derselben Umgebung zu haben, in der du den Code schreibst.
Der Grund ist simpel: kein Kontextwechsel. Du bist in einem Controller, willst wissen, was er zurückgibt, und der Request liegt zwei Tabs weiter statt in einer anderen Anwendung hinter einem Login.
Und weil die Requests reine Textdateien sind, kommen sie in git. Sie werden zusammen mit dem Endpunkt reviewt, den sie ausüben. Sie sind zu dem Commit korrekt, der sie eingeführt hat, für immer.
3. VS Code
Mit der REST-Client-Erweiterung schreibst du Requests in eine .http-Datei und klickst darüber auf "Send Request":
@host = localhost
@token = {{login.response.body.token}}
### login
# @name login
POST {{host}}/api/login
Content-Type: application/json
{ "email": "dev@example.com", "password": "secret" }
### eine Bewerbung anlegen
POST {{host}}/api/applications
Authorization: Bearer {{token}}
Content-Type: application/json
{ "title": "Backend Developer" }
Was es wirklich gut kann: Klartext sein. Diese Datei ist diffbar, reviewbar, greppbar und versioniert. Variablen können auf eine frühere Antwort verweisen, der Einloggen-dann-Token-nutzen-Ablauf funktioniert also ohne jedes Scripting.
Wo es wehtut: Es ist eine Erweiterung, also eine Abhängigkeit von jemandes Plugin statt vom Editor. Die Formatierung der Antwort ist rudimentär. Und es gibt keinen Umgebungswechsel, den eine nicht-technische Person zugänglich fände.
Nimm es für: Teams, die schon auf VS Code standardisiert sind und ihre Requests im Repository haben wollen.
4. PhpStorm
Vor allem für PHP-Entwickler interessant, klar. PhpStorm hat dasselbe .http-Format eingebaut — ohne Erweiterung — plus ein paar Dinge, die in der Praxis zählen.
Was es wirklich gut kann: dein Projekt kennen. Es liest Endpunkte aus dem Routing deines Frameworks, kann also eine URL vervollständigen, die du noch gar nicht aufgeschrieben hast. Es merkt sich jede Antwort. Und Umgebungen leben in einer separaten http-client.env.json, mit einem .private.json-Geschwister für Secrets, das du per gitignore ausschließt — was das "wie teilen wir Requests, ohne Zugangsdaten zu teilen"-Problem sauber löst.
Das Große: Ein aus der IDE abgefeuerter Request kann im selben Fenster den Debugger auslösen. Request schicken, auf deinem Breakpoint landen, durch den Controller steppen. Diese Schleife ist schwer zu schlagen.
Wo es wehtut: Es ist PhpStorm. Kostenpflichtig, schwer, und nutzlos für die Hälfte deines Teams, die einen anderen Editor nutzt.
Wie du tatsächlich wählst
Nicht "welcher ist der beste" — wähl nach deiner Situation.
Alle im Team sind Entwickler und nutzen dieselbe IDE? Nimm den IDE-Client und committe die .http-Dateien. Requests in git, reviewt mit dem Code, kein separates Werkzeug zu verwalten.
Gemischtes Team, oder Leute außerhalb der Entwicklung müssen Requests schicken? Postman, mit der Collection ins Repository exportiert, damit sie nicht in einem Workspace gefangen ist.
Andere Leute konsumieren deine API? Swagger UI, aus dem Code erzeugt. Nicht statt der anderen — zusätzlich.
Der beste REST-Client ist der, den dein ganzes Team öffnen kann. Das ist meistens nicht der mit den meisten Funktionen.
Den ich am wenigsten nutze
Ehrlich? Alle, für meine eigenen APIs. Wenn ich einen Endpunkt baue, schreibe ich stattdessen den Funktionstest — er hält dieselbe URL, denselben Body und denselben Auth-Header, er läuft mit einem Tastendruck, und anders als jeder Request in jedem Client prüft er den Endpunkt auch nächstes Jahr noch. Dieses Argument in voller Länge steht hier.
Ihren Platz verdienen sich die Clients bei der API von jemand anderem, wo es keine Testsuite und keinen Quellcode gibt — nur eine Basis-URL und eine Doku, von der du hoffst, dass sie aktuell ist.