DEV Community

Cover image for Top leichtgewichtige CLI-Tools für die Softwareentwicklung
Emre Demir
Emre Demir

Posted on • Originally published at apidog.com

Top leichtgewichtige CLI-Tools für die Softwareentwicklung

Der Großteil des Arbeitstags eines Backend-Entwicklers besteht aus kurzen Feedback-Schleifen: Anfrage senden, JSON prüfen, anpassen, wiederholen. Wenn dafür jedes Mal eine schwere GUI starten muss, kostet das mehr Zeit als die eigentliche API-Arbeit.

Teste Apidog noch heute

Leichte CLI-Tools verkürzen diese Schleife. Sie starten schnell, benötigen wenig Konfiguration und lassen sich direkt in Shell-Skripte und CI-Jobs integrieren. Für typische API- und Backend-Aufgaben reichen oft einige wenige Werkzeuge: HTTP-Anfragen senden, JSON parsen, lokale Ports freigeben, HTTPS einrichten, Dateien überwachen und Tests ausführen.

Dieser Leitfaden zeigt zehn Tools, die in den PATH eines Backend-Entwicklers gehören. Jeder Abschnitt enthält einen sofort nutzbaren Befehl. Für den größeren Kontext rund um Endpunkte, Spezifikationen und Workflows siehe den Leitfaden zur API-Entwicklung.

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

„Leichtgewichtig“ bedeutet geringer Fußabdruck und wenig Reibung — nicht möglichst viele Funktionen in einem Tool. Bewerte Tools anhand dieser vier Kriterien:

  • Installation: Eine einzelne Binärdatei oder ein kleines npx-Paket ist einfacher als zusätzliche Laufzeitumgebungen und Lockfiles.
  • Startgeschwindigkeit: Ein Tool sollte praktisch sofort verfügbar sein, besonders in wiederholten Shell-Schleifen.
  • Zeit bis zum ersten Ergebnis: Gute Standardwerte sind wichtiger als Projektdateien, Konten oder Dashboards vor dem ersten Befehl.
  • Zusammensetzbarkeit: Das Tool sollte stdin lesen, stdout schreiben, brauchbare Exit-Codes liefern und sich pipen lassen.

Die folgenden Tools reichen von kleinen Unix-artigen Helfern bis zu umfassenderen CLI-Workflows. curl ist häufig bereits installiert; der Rest lässt sich schnell ergänzen.

curl

curl ist der Standard für HTTP auf der Kommandozeile. Es ist auf fast jedem System verfügbar, funktioniert zuverlässig in Skripten und ist ideal für schnelle Checks oder reproduzierbare CI-Aufrufe.

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"}'
Enter fullscreen mode Exit fullscreen mode

Für robuste Skripte ergänze den Befehl gezielt:

curl --fail --silent --show-error \
  --write-out '\nHTTP %{http_code}\n' \
  https://api.example.com/health
Enter fullscreen mode Exit fullscreen mode
  • -s bzw. --silent unterdrückt die Fortschrittsanzeige.
  • -i zeigt Response-Header.
  • -w '%{http_code}' gibt Statusinformationen aus.
  • --fail liefert bei HTTP-Fehlern einen Exit-Code ungleich null — wichtig für CI.

Am besten geeignet für: Skripte, CI-Integritätsprüfungen und teilbare HTTP-Aufrufe.

Ehrliche Grenzen: Die Flag-Syntax ist dicht, und JSON-Bodies werden manuell zusammengesetzt. Für interaktive Requests sind HTTPie oder xh angenehmer.

HTTPie

HTTPie (http) macht manuelle API-Aufrufe lesbarer. JSON ist der Standard, die Ausgabe ist formatiert, und Request-Daten werden über einfache Request-Items statt vieler Flags angegeben.

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

Der Befehl sendet diesen JSON-Body:

{
  "name": "apidog",
  "role": "api-tool",
  "active": true
}
Enter fullscreen mode Exit fullscreen mode

Die wichtigsten Regeln:

  • name=value setzt einen String.
  • active:=true setzt einen rohen JSON-Wert.
  • Authorization:"Bearer $TOKEN" setzt einen Header.

Beispiel mit Authentifizierung:

http GET https://api.example.com/users \
  Authorization:"Bearer $TOKEN"
Enter fullscreen mode Exit fullscreen mode

Am besten geeignet für: Interaktive API-Erkundung, wenn Lesbarkeit wichtiger ist als minimale Startzeit.

Ehrliche Grenzen: HTTPie ist ein Python-Paket. Es benötigt Python und startet langsamer als eine native Binärdatei.

xh

xh übernimmt die Request-Syntax von HTTPie, wird aber als Rust-Binärdatei ausgeliefert. Damit bleibt die ergonomische Eingabe erhalten, während das Tool ohne Python-Laufzeit auskommt.

xh POST httpbin.org/post name=apidog age:=24
Enter fullscreen mode Exit fullscreen mode

Die Syntax entspricht HTTPie:

xh GET https://api.example.com/users \
  Authorization:"Bearer $TOKEN" \
  limit:=20
Enter fullscreen mode Exit fullscreen mode

xh eignet sich besonders für schlanke Container und CI-Images, weil keine zusätzliche Laufzeitumgebung erforderlich ist. Das Projekt stellt vorgefertigte Binärdateien für Linux, macOS und Windows bereit.

Am besten geeignet für: Teams, die HTTPie-Syntax mit nativer Geschwindigkeit und wenigen Abhängigkeiten kombinieren möchten.

Ehrliche Grenzen: xh deckt die gängige HTTPie-Oberfläche ab, aber nicht jedes Plugin.

jq

jq macht HTTP-Clients erst richtig skriptfähig. Statt komplette JSON-Antworten zu lesen, extrahierst oder transformierst du genau die Daten, die ein nachfolgender Shell-Schritt benötigt.

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

Typische Muster:

# Namen aus einem Array ausgeben
jq '.items[] | .name'

# Nur aktive Einträge auswählen
jq '.items[] | select(.active)'

# String ohne JSON-Anführungszeichen ausgeben
jq -r '.token'
Enter fullscreen mode Exit fullscreen mode

Beispiel für eine Shell-Variable:

API_URL=$(curl -s https://api.example.com/config | jq -r '.apiUrl')
Enter fullscreen mode Exit fullscreen mode

Am besten geeignet für: JSON-Felder in Skripten und CI extrahieren, filtern und umformen.

Ehrliche Grenzen: Komplexe Abfragen können kryptisch werden. Für einfachen Feldzugriff ist jq jedoch schnell gelernt.

gh (GitHub CLI)

gh bringt GitHub-Workflows ins Terminal. Nach einer einmaligen Anmeldung mit gh auth login kannst du Pull Requests, Issues, Releases und API-Aufrufe ohne manuelle Token-Verwaltung ausführen.

gh pr create --title "Add rate limiting" --body "Closes #42" --base main
Enter fullscreen mode Exit fullscreen mode

Nützliche Befehle für den täglichen Workflow:

# CI-Checks eines Pull Requests prüfen
gh pr checks

# GitHub-Actions-Workflow live verfolgen
gh run watch

# Beliebigen GitHub-API-Endpunkt authentifiziert aufrufen
gh api repos/OWNER/REPO/issues
Enter fullscreen mode Exit fullscreen mode

Am besten geeignet für: GitHub-Automatisierung in lokalen Skripten und CI-Pipelines.

Ehrliche Grenzen: Das Tool ist ausschließlich für GitHub relevant.

ngrok

ngrok macht einen lokalen Port über eine öffentliche HTTPS-URL erreichbar. Das ist besonders praktisch für Webhooks, OAuth-Callbacks oder Tests, bei denen ein externer Dienst deinen lokalen Server erreichen muss.

ngrok http 8080
Enter fullscreen mode Exit fullscreen mode

Der Befehl leitet eine öffentliche https://-URL an localhost:8080 weiter. Zusätzlich steht ein Traffic-Inspektor bereit:

http://127.0.0.1:4040
Enter fullscreen mode Exit fullscreen mode

Dort kannst du eingehende Requests prüfen und erneut abspielen — hilfreich beim Debuggen von Zahlungs-, Git- oder anderen Webhooks.

Am besten geeignet für: Webhook-Entwicklung, externe Callback-Tests und das Teilen eines lokalen Dev-Servers.

Ehrliche Grenzen: ngrok ist ein kommerzieller Dienst mit kostenlosem Tarif. Im Free-Plan ändern sich URLs zwischen Sitzungen und es gelten Limits.

mkcert

mkcert erstellt lokal vertrauenswürdige HTTPS-Zertifikate. Damit testest du https://localhost, Secure Cookies und OAuth-Redirects ohne Browser-Warnungen oder manuelle OpenSSL-Konfiguration.

mkcert -install
mkcert localhost 127.0.0.1 myapp.local
Enter fullscreen mode Exit fullscreen mode

Die Schritte:

  1. mkcert -install erstellt und installiert einmalig eine lokale Zertifizierungsstelle.
  2. mkcert localhost 127.0.0.1 myapp.local erzeugt Zertifikat und Schlüssel für die angegebenen Hosts.
  3. Übergib die erzeugten Dateien an deinen Entwicklungsserver oder Reverse Proxy.

Am besten geeignet für: Lokales HTTPS, das sich wie eine produktionsnahe Umgebung verhält.

Ehrliche Grenzen: Verwende mkcert-Zertifikate niemals in Produktion. Schütze außerdem den erzeugten Root-CA-Schlüssel, da er Zertifikate für jeden Namen auf deinem Rechner signieren kann.

watchexec

watchexec führt Befehle erneut aus, sobald sich Dateien ändern. Es eignet sich für Tests, lokale Server und andere enge Edit-Run-Schleifen. Standardmäßig berücksichtigt es .gitignore.

watchexec -e py -r 'pytest tests/'
Enter fullscreen mode Exit fullscreen mode

Weitere typische Einsätze:

# Go-Server bei Änderungen neu starten
watchexec -r 'go run .'

# JavaScript-Tests erneut ausführen
watchexec 'npm test'
Enter fullscreen mode Exit fullscreen mode
  • -e py beschränkt die Überwachung auf Python-Dateien.
  • -r beendet den alten langlebigen Prozess vor dem Neustart.

Am besten geeignet für: Sprachunabhängige Watch-Workflows für Tests und lokale Server.

Ehrliche Grenzen: watchexec startet Prozesse neu, bietet aber keinen Hot-Module-Reload und erhält keinen In-Process-Zustand.

Docker CLI

Die Docker CLI ist das schwerste Tool in dieser Liste, aber für lokale Infrastruktur oft unverzichtbar. Mit einem Befehl startest du eine echte Datenbank oder einen Cache, ohne Dienste dauerhaft auf dem Host einzurichten.

docker run --rm -e POSTGRES_PASSWORD=dev -p 5432:5432 postgres:16
Enter fullscreen mode Exit fullscreen mode

Danach verbindet sich deine Anwendung mit:

localhost:5432
Enter fullscreen mode Exit fullscreen mode

Die wichtigen Optionen:

  • --rm entfernt den Container beim Beenden.
  • -e setzt Umgebungsvariablen.
  • -p veröffentlicht einen Container-Port auf dem Host.

Dasselbe Muster funktioniert auch für andere Dienste:

docker run --rm -p 6379:6379 redis:7
Enter fullscreen mode Exit fullscreen mode

Am besten geeignet für: Reproduzierbare lokale Abhängigkeiten und Integrationstests.

Ehrliche Grenzen: Docker benötigt einen laufenden Daemon sowie Speicher und Festplatte. Die CLI selbst bleibt aber gut skriptbar.

apidog-cli

Sobald du API-Aufgaben über die Kommandozeile ausführst, fehlt häufig die Verbindung zum eigentlichen API-Projekt: Endpunkte, Schemas, Umgebungen und Testszenarien. Apidog stellt dafür apidog-cli bereit, um diese Ressourcen aus dem Terminal zu verwenden.

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

apidog run führt ein gespeichertes Testszenario gegen eine Umgebung aus und gibt die einzelnen Ergebnisse im Terminal aus. Bei erfolgreichen Assertions endet der Prozess mit Exit-Code 0; bei Fehlern mit einem Exit-Code ungleich null. Damit lässt sich der Befehl direkt als CI-Gate verwenden.

Beispiel für einen CI-Schritt:

apidog run \
  -t "$APIDOG_SCENARIO_ID" \
  -e "$APIDOG_ENV_ID" \
  -r cli
Enter fullscreen mode Exit fullscreen mode

Die CLI deckt außerdem Befehlsgruppen für typische Projektaufgaben ab:

  • endpoint und schema für API-Design
  • import und export für OpenAPI-, Swagger- und Postman-Spezifikationen
  • mock für Mock-Erwartungen
  • environment und variables für Konfiguration

Die Ausgabe ist strukturiertes JSON mit agentHints.nextSteps. Dadurch passt die CLI auch zu KI-Codierungsassistenten für die API-Entwicklung.

Weitere Details findest du im vollständigen Apidog CLI-Leitfaden und im Apidog CLI-Installationsleitfaden.

Am besten geeignet für: Testszenarien in CI ausführen und API-Projektressourcen per Skript verwalten — besonders in einem Spec-First-API-Entwicklungs-Workflow.

Ehrlicher Hinweis: Apidog ist keine Open-Source-Software, sondern ein kommerzielles Produkt mit kostenlosem Tarif. Die CLI verbindet Request-Workflows, Mocks und Tests mit einem gemeinsamen Projekt. apidog-cli ist das leichtgewichtige Terminal-Werkzeug; die vollständige Apidog-Plattform bietet zusätzlich eine GUI für dasselbe Projekt.

Wie man wählt

Die Tools ergänzen sich meist, statt direkt miteinander zu konkurrieren. Ein praxistaugliches Setup kombiniert normalerweise 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ähle nach Aufgabe:

  • Anfragen senden: xh oder HTTPie interaktiv, curl für Skripte.
  • JSON lesen und transformieren: jq.
  • Lokalen Port freigeben: ngrok.
  • Lokales HTTPS einrichten: mkcert.
  • Beim Speichern neu starten: watchexec.
  • Datenbanken und Dienste starten: Docker.
  • API-Tests und Projektressourcen steuern: apidog-cli.

Zusammenfassung

Ein gutes leichtgewichtiges Backend-Setup besteht aus kleinen Tools, die jeweils eine Aufgabe zuverlässig erledigen und sich kombinieren lassen:

curl -s https://api.example.com/users \
  | jq -r '.items[] | .email'
Enter fullscreen mode Exit fullscreen mode

curl und xh senden Requests, jq verarbeitet Antworten, ngrok und mkcert vereinfachen lokale Integrationen, watchexec verkürzt den Edit-Run-Loop und Docker liefert reproduzierbare Infrastruktur.

apidog-cli verbindet diese Terminal-Workflows mit deinem API-Projekt, sodass dieselben Endpunkte und Tests in Entwicklung, Team-Workflow und CI verwendet werden. Lade Apidog herunter, richte ein Projekt ein und automatisiere anschließend Tests und API-Aufgaben über die CLI.

Top comments (0)