Top leichtgewichtige CLI-Tools für die Softwareentwicklung

Der Großteil des Arbeitstages eines Backend-Entwicklers besteht aus kleinen, schnellen Schleifen. Eine Anfrage an einen Endpunkt senden, das JSON lesen, anpassen, wiederholen. Wenn man dafür eine schwere grafische Benutzeroberfläche (GUI) verwendet, verbringt man mehr Zeit mit dem Warten auf das Laden als mit der eigentlichen Arbeit.

Leichte CLI-Tools kehren das um. Sie werden als einzelne Binärdatei oder als über `npx` installierbares Paket ausgeliefert, starten in deutlich weniger als einer Sekunde und erledigen eine Aufgabe ohne Konfigurationsassistenten. Man bindet sie in Shell-Skripte und CI-Jobs ein, und sie stehen nicht im Weg. Für API- und Backend-Arbeiten deckt ein kleines Set dieser Tools den größten Teil des Zyklus ab: Anfragen senden, Antworten parsen, einen lokalen Port freigeben und die Testsuite ausführen.

Dieser Leitfaden stellt zehn Tools vor, die einen Platz im `PATH` eines Backend-Entwicklers verdienen. Jeder Abschnitt zeigt den einen Befehl, der ihre Funktionsweise demonstriert. Das Thema ist der Fußabdruck: Was sich schnell installieren, schnell starten lässt und kaum etwas verlangt, bevor es nützlich ist. Für das Gesamtbild, wie diese zusammenpassen, bietet der Leitfaden zur API-Entwicklung den Kontext.

Schaltfläche

Was macht ein CLI-Tool für die Entwicklung „leichtgewichtig“?

Leichtgewichtig bedeutet geringer Fußabdruck und wenig Reibung, nicht wie viele Funktionen ein Tool zusammenpresst. Wenn Sie entscheiden, was zu Ihrem Werkzeugsatz gehört, wägen Sie vier Dinge ab:

Installationsgröße und -form. Eine einzelne statische Binärdatei oder ein kleines `npx`-Paket schlägt alles, was eine Laufzeitumgebung und eine Lockfile mit sich zieht.
Startgeschwindigkeit. Das Tool sollte laufen, bevor Sie wieder zu Ihrem Editor gewechselt haben. Rust- und Go-Binärdateien starten in Millisekunden kalt, was wichtig ist, wenn Sie sie in einer Schleife aufrufen.
Konfiguration bis zum ersten Ergebnis. Eine nützliche Standardeinstellung ohne Konfiguration ist die Messlatte. Wenn es zuerst eine Projektdatei, ein Konto und ein Dashboard benötigt, ist es nicht leichtgewichtig.
Zusammensetzbarkeit. Es liest von stdin, schreibt auf stdout, setzt einen echten Exit-Code und kann in das nächste Tool gepiped werden. Das macht ein kleines Tool wertvoller als seine Größe.

Die unten aufgeführten Tools reichen grob von den kleinsten und zweckmäßigsten bis zu den umfassenderen. curl ist bereits auf Ihrem Rechner; der Rest ist schnell installiert.

curl

curl ist der Maßstab, an dem sich jedes andere HTTP-Tool misst. Es ist bereits auf fast jedem Rechner vorhanden, spricht jedes Protokoll, mit dem Sie in Berührung kommen, und tut genau das, was Sie ihm sagen. Für eine schnelle Überprüfung, ob ein Endpunkt aktiv ist, gibt es nichts Schnelleres.

curl -s -X POST https://api.github.com/repos/curl/curl/issues \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Test issue"}'

Das -s unterdrückt die Fortschrittsanzeige, sodass die Antwort sauber ausgegeben wird. Fügen Sie -i hinzu, um Header zu sehen, -w '%{http_code}', um nur den Statuscode auszugeben, und --fail, damit curl bei einem 4xx oder 5xx einen Exit-Code ungleich Null zurückgibt, was Sie in einem CI-Check wünschen.

Am besten geeignet für: Skripte, CI-Integritätsprüfungen und jede Anfrage, die Sie kopieren, einfügen und teilen möchten. Ein curl-Befehl funktioniert auf jedem Computer eines Teammitglieds.

Ehrliche Grenzen: Die Flag-Syntax ist dicht und die JSON-Body-Behandlung ist manuell. Für schnelle interaktive Anfragen sind die nächsten beiden Tools benutzerfreundlicher.

HTTPie

HTTPie (http) ist curl, bei dem die scharfen Kanten geglättet wurden, gebaut für Menschen, die Anfragen von Hand eingeben. JSON ist der Standard, die Ausgabe ist farbig und formatiert, und Sie erstellen eine Anfrage aus einfachen key=value-Elementen, anstatt sich Flags merken zu müssen.

http POST httpbin.org/post name=apidog role=api-tool active:=true

Das sendet einen JSON-Body von {"name": "apidog", "role": "api-tool", "active": true}. Das = setzt einen String, := setzt einen rohen JSON-Wert und header:value setzt einen Header. Kein Anführungszeichen für einen JSON-Blob, keine -H- und -d-Buchführung. Die Antwort kommt schön formatiert zurück.

Am besten geeignet für: Interaktive API-Erkundung, bei der Lesbarkeit gewinnt.

Ehrliche Grenzen: Es ist ein Python-Paket, daher startet es langsamer als eine native Binärdatei und benötigt Python auf dem Rechner. Wenn die Startgeschwindigkeit wichtig ist, verwenden Sie xh.

xh

xh ist HTTPies Syntax in einer einzigen Rust-Binärdatei. Es implementiert den HTTPie-Anfrage-Item-Stil neu, sodass name=value und := gleich funktionieren, aber es wird als eine statisch verknüpfte Datei ohne Laufzeitumgebung ausgeliefert und startet etwa 30 % schneller. Es unterstützt auch HTTP/2 und HTTP/3.

xh POST httpbin.org/post name=apidog age:=24

Gleiche Ergonomie wie HTTPie, nahezu sofortiger Start. Da es sich um eine einzelne Binärdatei ohne Abhängigkeiten handelt, lässt es sich in ein schlankes CI-Image oder einen Container einfügen, ohne Python mitzuziehen. Das xh-Projekt auf GitHub liefert vorgefertigte Binärdateien für Linux, macOS und Windows.

Am besten geeignet für: Entwickler, die das HTTPie-Gefühl mögen, aber native Geschwindigkeit und eine Installation ohne Abhängigkeiten für Skripte und Container wünschen.

Ehrliche Grenzen: Es deckt die gängige HTTPie-Oberfläche ab, nicht jedes einzelne Plugin. Für fast alle Anfragen fällt dieser Unterschied nie auf.

jq

jq macht jedes andere HTTP-Tool nützlicher. Es ist eine einzelne Binärdatei, die JSON auf der Kommandozeile filtert und umformt, sodass Sie ein Feld aus einer API-Antwort extrahieren können, anstatt den gesamten Datenblock zu überfliegen.

curl -s https://api.github.com/repos/stedolan/jq | jq '.stargazers_count'

Das gibt nur die Sternenanzahl aus. jq verfügt über eine vollständige Abfragesprache: .items[] | .name iteriert über ein Array, select(.active) filtert und -r gibt eine Rohausgabe ohne Anführungszeichen, sodass Sie sie in eine Shell-Variable pipen können. Es ist das Bindeglied zwischen einem API-Aufruf und dem Rest Ihres Skripts.

Am besten geeignet für: Extrahieren und Transformieren von Feldern aus JSON-Antworten in Skripten und CI.

Ehrliche Grenzen: Die Abfragesyntax hat eine Lernkurve, und tief verschachtelte Transformationen können kryptisch werden. Für den einfachen Feldzugriff ist sie trivial.

gh (GitHub CLI)

gh bringt die GitHub-API in Ihr Terminal, ohne dass Sie einen einzigen curl-Aufruf dagegen schreiben müssen. Es handhabt die Authentifizierung einmal über gh auth login und wickelt dann Pull Requests, Issues, Releases und Repos in einfachen Befehlen ab. Für Backend-Teams, deren Bereitstellungs- und Überprüfungsprozess auf GitHub stattfindet, entfällt ein Browser-Tab aus der Schleife.

gh pr create --title "Add rate limiting" --body "Closes #42" --base main

Das öffnet einen PR von Ihrem aktuellen Branch. gh pr checks überwacht CI, gh run watch verfolgt einen Workflow live, und gh api bietet Ihnen einen authentifizierten, paginierten Client für jeden Endpunkt, den die umhüllten Befehle nicht abdecken.

Am besten geeignet für: Das Skripten von GitHub selbst: PRs aus CI öffnen, Releases erstellen und die API abfragen, ohne Tokens manuell verwalten zu müssen.

Ehrliche Grenzen: Es ist nur für GitHub, ein GitLab- oder Bitbucket-Shop profitiert davon nicht.

ngrok

ngrok macht einen lokalen Port über einen sicheren Tunnel für eine öffentliche URL zugänglich. Sie entwickeln einen Webhook-Handler oder brauchen jemanden, der Ihren Dev-Server von außerhalb Ihres Netzwerks erreicht? Es verwandelt localhost mit einem einzigen Befehl in einen teilbaren Link. Der Agent ist eine binäre Datei ohne Abhängigkeiten, die überall läuft.

ngrok http 8080

Das leitet eine öffentliche `https://`-URL an Ihren lokalen Port 8080 weiter und gibt sie im Terminal aus. Es führt auch einen Traffic-Inspektor unter http://127.0.0.1:4040 aus, wo Sie jede eingegangene Anfrage wiedergeben können, was eine echte Zeitersparnis ist, wenn Sie einen Zahlungs- oder Git-Webhook debuggen, den Sie nicht kontrollieren.

Am besten geeignet für: Webhook-Entwicklung, das Teilen einer in Arbeit befindlichen Anwendung mit einem Teamkollegen und das Testen von Rückrufen Dritter mit lokalem Code.

Ehrliche Grenzen: Es ist ein kommerzieller Dienst mit einem kostenlosen Tarif; der kostenlose Plan rotiert Ihre URL bei jeder Sitzung und drosselt sie. Für stabiles lokales HTTPS mit einem festen Namen verwenden Sie stattdessen mkcert.

mkcert

mkcert erstellt lokal vertrauenswürdige HTTPS-Zertifikate ohne Konfiguration. Es wurde in Go von Filippo Valsorda geschrieben und ist eine einzelne Binärdatei, die eine lokale Zertifizierungsstelle erstellt, diese in Ihren System-Vertrauensspeicher installiert und Zertifikate ausstellt, die Ihr Browser ohne Warnung akzeptiert. So betreiben Sie https://localhost lokal ohne das beängstigende rote Vorhängeschloss.

mkcert -install
mkcert localhost 127.0.0.1 myapp.local

Die erste Zeile richtet die lokale CA einmalig ein. Die zweite Zeile stellt ein Zertifikat und einen Schlüssel für die von Ihnen aufgeführten Namen aus, bereit zur Übergabe an Ihren Entwicklungsserver oder Reverse-Proxy. Keine OpenSSL-Befehlszeilen-Beschwörungen, kein selbstsigniertes Zertifikat, das Sie bei jedem Neuladen wegklicken. Das Testen von OAuth-Weiterleitungen, sicheren Cookies oder allem, was sich über HTTPS anders verhält, wird erheblich einfacher.

Am besten geeignet für: Das Einrichten von echtem, vertrauenswürdigem HTTPS in einer lokalen Entwicklungsumgebung, damit es der Produktion entspricht.

Ehrliche Grenzen: Es ist nur für die Entwicklung gedacht. Verwenden Sie mkcert-Zertifikate niemals in der Produktion und schützen Sie den von ihm generierten Root-CA-Schlüssel; er kann für jeden Namen auf Ihrem Computer signieren.

watchexec

watchexec führt einen Befehl erneut aus, wenn sich Dateien ändern. Es ist eine einzelne Rust-Binärdatei, die ein Verzeichnis überwacht und Ihren Server neu startet oder Ihre Tests erneut ausführt, sobald Sie speichern. Es respektiert standardmäßig `.gitignore`, sodass es nicht auf Build-Artefakte reagiert.

watchexec -e py -r 'pytest tests/'

Das -e py filtert nach Python-Dateien, und -r startet einen langlebigen Prozess neu, anstatt neue zu stapeln. Zeigen Sie es auf jeden Befehl: watchexec -r 'go run .' für einen Go-Server, watchexec 'npm test' für eine JS-Suite. Es ist sprachunabhängig, sodass ein Tool jedes Projekt abdeckt, anstatt einen Stack-spezifischen Watcher zu verwenden.

Am besten geeignet für: Enge Bearbeitungs- und Ausführungszyklen auf einem lokalen Server oder einer Testsuite, ohne einen Framework-spezifischen Watch-Modus.

Ehrliche Grenzen: Es überwacht und führt erneut aus; es bietet keinen Hot-Module-Reload oder bewahrt den In-Process-Zustand.

Docker CLI

Die Docker CLI ist das schwerste Tool hier, und es verdient seinen Platz. Wenn Sie ein echtes Postgres, Redis oder eine ganze Abhängigkeit für die lokale Entwicklung benötigen, gibt Ihnen ein docker run eine temporäre Instanz, die Sie entsorgen können, wenn Sie fertig sind. Keine systemweite Installation, keine übrig gebliebenen Dienste.

docker run --rm -e POSTGRES_PASSWORD=dev -p 5432:5432 postgres:16

Das --rm löscht den Container beim Beenden, -e setzt das Passwort und -p bildet den Port auf Ihren Host ab. Ihre App verbindet sich mit localhost:5432 und Sie erhalten bei jedem Lauf eine saubere Datenbank. Ersetzen Sie postgres:16 durch redis:7 oder ein beliebiges Image, und das Muster bleibt bestehen.

Am besten geeignet für: Das Starten unterstützender Dienste für die lokale Entwicklung und Integrationstests, reproduzierbar, ohne Ihren Rechner zu zumüllen.

Ehrliche Grenzen: Es ist nicht leichtgewichtig im binären Sinne; es benötigt einen laufenden Daemon und echten Speicher und Festplatte. Aber die CLI ist skriptfähig und terminalzentriert, und für reproduzierbare lokale Infrastruktur kommt nichts anderes heran.

apidog-cli

Sobald Sie API-Arbeit über die Kommandozeile erledigen, ist das fehlende Teil Ihr eigentliches API-Projekt: dessen Endpunkte, Schemata, Umgebungen und Testszenarien. Apidog liefert apidog-cli, das leichtgewichtige CLI, das das Terminal mit diesem Projekt verbindet. Es wird als einzelnes npm-Paket installiert und bietet Ihnen einen skriptfähigen Pfad zum Entwerfen, Importieren, Mocken und Testen von Ressourcen, ohne die Desktop-App öffnen zu müssen.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run -t <scenario_id> -e <env_id> -r cli

apidog run führt ein gespeichertes Testszenario gegen eine Umgebung aus und druckt ein schrittweises Ergebnis im Terminal. Es beendet mit 0, wenn alle Assertions erfolgreich sind, und mit einem Wert ungleich Null bei Fehlschlag, sodass es direkt in ein CI-Gate passt. Neben Tests deckt die CLI reale Befehlsgruppen ab: endpoint und schema für das Design, import und export für das Verschieben von Spezifikationen (OpenAPI, Swagger, Postman) hinein und hinaus, mock für Mock-Erwartungen sowie environment und variables für die Konfiguration. Die Ausgabe ist strukturiertes JSON mit agentHints.nextSteps, weshalb es auch gut zu KI-Codierungsassistenten passt, die API-Entwicklung betreiben. Für die vollständige Befehlsreferenz siehe den vollständigen Apidog CLI-Leitfaden; der Apidog CLI-Installationsleitfaden erklärt den ersten Start.

Am besten geeignet für: Das Ausführen Ihrer Testszenarien in CI und das Verwalten von Projektressourcen aus Skripten, insbesondere in einem Spec-First-API-Entwicklungs-Workflow, bei dem der Vertrag alles steuert.

Ehrlicher Hinweis: Apidog ist keine Open-Source-Software; es ist ein kommerzielles Produkt mit einem kostenlosen Tarif. Aber dieser kostenlose Tarif plus die CLI bietet Ihnen eine integrierte Alternative zum selbstständigen Zusammenfügen eines Request-Clients, eines Mock-Servers und eines Test-Runners, alles unterstützt von einem einzigen Projekt. Das leichtgewichtige Stück ist die Binärdatei apidog-cli; die vollständige Apidog-Plattform ist eine GUI auf demselben Projekt.

Wie man wählt

Die meisten dieser Tools ergänzen sich, anstatt zu konkurrieren. Sie werden wahrscheinlich mehrere verwenden: einen HTTP-Client, jq, einen Tunnel, einen Watcher und einen Test-Runner.

Tool	Am besten geeignet für	Installation	Open Source?
curl	Skriptgesteuerte Anfragen, CI-Integritätsprüfungen	vorinstalliert	Ja (curl Lizenz)
HTTPie	Lesbare interaktive Anfragen	`pip install httpie`	Ja (BSD)
xh	HTTPie-Gefühl, native Geschwindigkeit	`cargo install xh` / Binärdatei	Ja (MIT)
jq	Filtern von JSON-Antworten	`brew install jq` / Binärdatei	Ja (MIT)
gh	Skripten von GitHub-PRs und CI	`brew install gh` / Binärdatei	Ja (MIT)
ngrok	Freigabe von Localhost, Webhooks	Binärdatei herunterladen	Nein (Freemium)
mkcert	Vertrauenswürdige lokale HTTPS-Zertifikate	`brew install mkcert` / Binärdatei	Ja (BSD)
watchexec	Neustart bei Dateiänderung	`cargo install watchexec-cli`	Ja (Apache-2.0)
Docker CLI	Temporäre unterstützende Dienste	Docker-Installation	Ja (Apache-2.0)
apidog-cli	Testszenarien ausführen, Projekt verwalten	`npm install -g apidog-cli`	Nein (Freemium)

Wählen Sie nach der Aufgabe. Anfragen senden: xh oder HTTPie für interaktive Arbeit, curl für Skripte. Antworten lesen: immer jq. Einen Port freigeben: ngrok. Lokales HTTPS: mkcert. Neustart beim Speichern: watchexec. Unterstützende Dienste: Docker. Ihre API-Tests ausführen und das Projekt verwalten: apidog-cli.

Zusammenfassung

Ein gutes, leichtgewichtiges Set besteht aus einer Handvoll kleiner, schneller Tools, die jeweils eine Aufgabe erledigen und in das nächste pipen. curl und xh senden Anfragen, jq liest sie, ngrok und mkcert handhaben den lokalen Zugriff, watchexec schließt den Edit-Run-Loop und Docker bietet Ihnen eine Wegwerf-Infrastruktur. Keines davon verlangt viel, bevor es nützlich ist.

apidog-cli ist das Stück, das die Schleife wieder mit Ihrem eigentlichen API-Projekt verbindet, sodass die Endpunkte und Tests, die Sie vom Terminal aus ausführen, dieselben sind, die Ihr Team entwirft und bereitstellt. Laden Sie Apidog herunter, um ein Projekt einzurichten, und steuern Sie es dann über die Befehlszeile mit der CLI in Ihrer CI-Pipeline. Dieselbe Idee von Geschwindigkeit und geringem Fußabdruck, angewendet auf den gesamten API-Lebenszyklus statt auf einzelne Anfragen.