Kostenlose Open Source CLI-Tools für die Entwicklung

Die meisten Entwickler-Workflows laufen immer noch über das Terminal, und die Tools, die sich über Jahre bewähren, teilen oft eine Eigenschaft: Sie sind Open Source. Man kann den Code lesen, alles, was einen Server betreibt, selbst hosten und stößt nie auf eine Sitzplatzlizenz oder eine „Vertrieb kontaktieren“-Grenze. Wenn ein Tool unter MIT- oder Apache-Lizenz steht und auf GitHub liegt, erhält man auch ein Wartungssignal, das man selbst überprüfen kann, plus die Freiheit, es zu forken, wenn das Projekt stagniert.

Dieser Beitrag ist eine kuratierte Liste kostenloser, wirklich quelloffener CLI-Tools, die sich im täglichen API-Entwicklung- und Backend-Bereich bewährt haben. Jedes hier vorgestellte Tool wird unter einer permissiven oder Copyleft-Lizenz geliefert, behält seinen Quellcode auf GitHub und verursacht keine Kosten im Betrieb. Der Fokus liegt auf Lizenz und Vendor Lock-in, nicht auf der reinen Größe oder Startgeschwindigkeit.

Sie erhalten sieben Tools für den Kern-Workflow: Anfragen stellen, JSON parsen, HTTP-Flüsse testen, mit GitHub arbeiten und einen lokalen Server dem Internet zugänglich machen. Jeder Eintrag nennt die Lizenz, verlinkt das Repository und zeigt einen echten Befehl, damit Sie sehen können, wie es funktioniert. Es gibt auch einen ehrlichen Hinweis darauf, wo ein kommerzielles Tool mit kostenloser Stufe passt, klar gekennzeichnet, damit Sie es nie mit einem Open-Source-Eintrag verwechseln.

Was ein CLI-Tool für die Entwicklung „Open Source“ macht

Viele Tools sind kostenlos herunterzuladen, aber im Kern geschlossen, oder im Kern offen, wobei die nützlichen Teile hinter einer Paywall liegen. Für diese Liste qualifiziert sich ein Tool nach drei Kriterien:

• Lizenz. Es wird unter einer OSI-anerkannten Lizenz geliefert: MIT, Apache 2.0, BSD oder GPL. Das ermöglicht Ihnen die kommerzielle Nutzung, das Selbst-Hosting und das Forken ohne Nachfrage.
• Quellcode auf GitHub (oder Ähnlichem). Sie können jede Zeile lesen, Issues einreichen und die Wartung anhand der Commit-Historie und der Release-Kadenz beurteilen.
• Kein Vendor Lock-in. Kein obligatorisches Konto, keine Telemetrie, die Sie nicht deaktivieren können, keine Serverkomponente, die Sie mieten müssen. Wenn es einen Dienst betreibt, können Sie diesen Dienst selbst betreiben.

Sterne und aktuelle Commits sind auch wichtig, aber zweitrangig. Ein ruhiges, stabiles MIT-Tool ist besser als ein trendiges mit einer Source-Available-Lizenz, die die kommerzielle Nutzung einschränkt. Überprüfen Sie die LICENSE-Datei, bevor Sie sich für etwas entscheiden.

curl: der universelle HTTP-Client

curl ist das Tool, an dem fast jedes andere HTTP-Tool gemessen wird. Es spricht Dutzende von Protokollen, ist standardmäßig auf fast jedem Betriebssystem vorhanden und wird seit 1996 kontinuierlich gewartet. Es ist unter der permissiven curl-Lizenz (einem MIT/X-Derivat) lizenziert, und der Quellcode befindet sich unter github.com/curl/curl.

Für die API-Arbeit ist curl Ihr kleinstes gemeinsames Vielfaches unter den Anfrage-Tools. Es ist bereits installiert, sodass jedes Skript oder jeder CI-Job sich darauf verlassen kann.

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","body":"Filed from curl"}'

Am besten geeignet für: Portabilität und Skripting. Wenn es eine Shell ausführt, führt es auch curl aus. Die ehrliche Grenze ist die Ergonomie. Rohe curl-Ausgabe ist dicht, die Header-Behandlung ist umständlich, und das Lesen eines JSON-Körpers bedeutet, ihn woandershin umzuleiten. Genau deshalb existieren die nächsten beiden Tools.

HTTPie: curl mit benutzerfreundlicher Ausgabe

HTTPie ist ein moderner HTTP-Client, der für Menschen und nicht nur für Skripte entwickelt wurde. Anfragen lesen sich wie einfaches Englisch, JSON ist der Standard-Body-Typ, und Antworten kommen farbig und formatiert zurück. Es ist unter BSD-3-Clause lizenziert und offen unter github.com/httpie/cli.

Installieren Sie es mit pip, dann verwenden Sie den Befehl http:

pip install httpie
http POST httpbin.org/post name=apidog role=platform

Das ist die ganze Anfrage. name=apidog wird automatisch zu einem JSON-Feld, Header und Status werden farbig ausgegeben, und der Body wird ohne ein zweites Tool hübsch formatiert. Am besten geeignet für: interaktive Erkundung und manuelles Debugging. Die ehrliche Einschränkung ist, dass es ein Python-Paket ist, also eine schwerere Installation als ein einzelnes statisches Binary, und in schlanken CI-Images greifen Sie möglicherweise immer noch zu curl.

jq: der JSON-Prozessor, den jede Pipeline braucht

APIs geben JSON zurück, und jq ist der Weg, wie Sie es von der Kommandozeile aus zerlegen. Es filtert, formt um und extrahiert Felder mit einer kleinen Abfragesprache und lässt sich sauber mit curl oder HTTPie in einer Pipe kombinieren. jq ist MIT-lizenziert und wird von der Community unter github.com/jqlang/jq gepflegt.

Leiten Sie eine API-Antwort direkt hinein:

curl -s https://api.github.com/repos/jqlang/jq \
  | jq '{name: .name, stars: .stargazers_count, license: .license.spdx_id}'

Das zieht drei Felder aus einer großen Antwort und erstellt ein sauberes Objekt. Am besten geeignet für: die Umwandlung von unübersichtlichem JSON in genau die Form, die Sie für den nächsten Schritt in einem Skript benötigen. Die ehrliche Grenze ist die Lernkurve. Die Syntax von jq ist mächtig, aber prägnant, und komplexe Transformationen können schnell kryptisch werden. Für die alltägliche Feldextraktion lernen Sie jedoch 90 % dessen, was Sie brauchen, an einem Nachmittag.

gh: die GitHub-CLI

gh bringt GitHub in Ihr Terminal: Pull Requests, Issues, Releases, Actions-Läufe und API-Aufrufe, alles ohne einen Browser zu öffnen. Es ist in Go geschrieben, MIT-lizenziert und befindet sich unter github.com/cli/cli. Da so viel API- und Backend-Arbeit in GitHub-Repos stattfindet, gehört es zum Kern-Kit.

Ein nützlicher Trick: gh api bietet Ihnen einen authentifizierten, paginierten Wrapper über die GitHub REST- und GraphQL-APIs, sodass Sie Token nicht manuell in curl einbetten müssen.

gh api repos/cli/cli/releases --jq '.[0].tag_name'

Das gibt den neuesten Release-Tag mithilfe des integrierten jq-Filters von gh aus. Am besten geeignet für: das Skripting von GitHub selbst, von CI-Workflows bis zur Release-Automatisierung. Die ehrliche Grenze ist der Umfang; es ist absichtlich nur für GitHub. Für GitLab oder Gitea benötigen Sie deren jeweilige CLIs oder einfaches curl gegen deren APIs.

Hurl: Klartext-HTTP-Tests, die Sie committen können

Hurl führt HTTP-Anfragen aus und testet sie, die in einer einfachen Klartextdatei definiert sind. Sie schreiben Anfragen, überprüfen Statuscodes, Header und JSON-Bodies und verketten Aufrufe, indem Sie Werte von einer Antwort in die nächste übernehmen. Es verwandelt „die API testen“ in eine Datei, die Sie in Git einchecken können. Hurl ist in Rust geschrieben, Apache 2.0-lizenziert und wird von Orange unter github.com/Orange-OpenSource/hurl gepflegt.

Erstellen Sie eine .hurl-Datei:

GET https://api.github.com/repos/Orange-OpenSource/hurl

HTTP 200
[Asserts]
jsonpath "$.name" == "hurl"
jsonpath "$.stargazers_count" > 1000

Führen Sie es dann aus:

hurl --test repo.hurl

Hurl beendet sich mit 0, wenn alle Zusicherungen erfolgreich sind, und mit einem Wert ungleich 0, wenn eine fehlschlägt, wodurch es direkt in CI integriert werden kann. Am besten geeignet für: lesbare, versionskontrollierte Integrationstests, die ein ganzes Team bearbeiten kann, ohne ein Framework lernen zu müssen. Die ehrliche Einschränkung ist, dass es sich auf HTTP-Anfrage-/Antworttests konzentriert; es ist kein vollständiges Vertragstest- oder Lasttest-Tool. Für einen breiteren Blick darauf, wie CLI-Tests in einen spec-first API-Entwicklungs-Workflow passen, lässt sich die Assertionsdatei gut mit einer OpenAPI-Quelle der Wahrheit kombinieren.

cloudflared: einen lokalen Server ohne bezahlten Tunnel zugänglich machen

Manchmal benötigen Sie eine öffentliche URL für die API, die auf Ihrem Laptop läuft: einen Webhook-Callback, eine Demo, einen mobilen Test gegen einen echten Host. cloudflared ist Cloudflares Tunnel-Client, und sein Quick-Tunnel-Modus bietet Ihnen eine temporäre öffentliche *.trycloudflare.com URL mit einem Befehl und ohne Konto. Es ist in Go geschrieben, Apache 2.0-lizenziert und offen unter github.com/cloudflare/cloudflared.

Richten Sie es auf Ihren lokalen Port:

cloudflared tunnel --url http://localhost:3000

Es gibt eine öffentliche HTTPS-URL aus, die an localhost:3000 weiterleitet, bis Sie es stoppen. Am besten geeignet für: schnelle, kostenlose, Ad-hoc-Tunnel, wenn Sie sich für nichts anmelden möchten. Wenn Sie lieber vollständig im npm-Ökosystem bleiben möchten, erledigt localtunnel (MIT) dieselbe Aufgabe mit npx localtunnel --port 3000. Die ehrliche Einschränkung bei Quick-Tunnels: Die URL ist zufällig und kurzlebig, und für stabile, benannte Tunnels müssen Sie ein Cloudflare-Konto und eine Konfiguration erstellen, obwohl der Client in beiden Fällen Open Source bleibt.

git: Versionskontrolle als CLI, nicht als GUI

Man vergisst leicht, dass Git zuerst ein Befehlszeilen-Tool ist. Jede API-Spezifikation, Testdatei und jedes Hurl-Szenario gehört in ein Git-Repository, und die CLI ist der Ort, an dem die wahre Macht liegt: präzises Staging, Bisect, Rebase und Hooks, die Ihre API-Tests vor einem Commit ausführen. git ist GPLv2-lizenziert und wird offen unter github.com/git/git entwickelt.

Ein kleines Beispiel, das das Kit zusammenführt: ein Pre-Commit-Hook, der Ihre Hurl-Tests ausführt, bevor Code übernommen wird.

echo 'hurl --test *.hurl' > .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit

Am besten geeignet für: als Grundlage, auf der alles andere aufbaut. Vom ersten Tag an selbst gehostet, kein Server erforderlich und in jeder Hinsicht formbar. Die ehrliche Einschränkung ist, dass Git Versionskontrolle ist, nicht Projekthosting; die Hosting-Schicht (GitHub, GitLab, Gitea) ist eine separate Wahl, und nur einige davon sind selbst Open Source.

Ein ehrlicher Exkurs: Wo Apidog passt

Apidog ist nicht Open Source, daher gehört es nicht als OSS-Eintrag auf diese Liste. Es ist ein kommerzielles Produkt mit einem kostenlosen Tarif und wird hier aus einem Grund genannt: Die oben genannten Tools sind einzeln hervorragend, aber man muss sie am Ende von Hand zusammenfügen. curl für Anfragen, jq zum Parsen, Hurl für Tests, ein separater Mock-Server, ein Dokumentationsgenerator, Umgebungsvariablen, die in Shell-Profilen verwaltet werden.

Apidog vereint Design, Testen, Mocking und Dokumentation in einem Arbeitsbereich, und apidog-cli bringt dies ins Terminal. Es ist ein npm-Paket (npm install -g apidog-cli) und führt Testszenarien aus, verwaltet Endpunkte und Schemas, startet Mock-Erwartungen und importiert oder exportiert OpenAPI, alles mit strukturierter JSON-Ausgabe, die Skripte und KI-Agenten lesen können. apidog run beendet sich mit 0 bei Erfolg und mit einem Wert ungleich 0 bei Misserfolg, sodass es wie Hurl direkt in CI integriert werden kann.

Die ehrliche Einordnung: Wenn Sie keinen Vendor Lock-in und vollen Quellcodezugriff wünschen, ist das Open-Source-Kit die richtige Wahl, und darum geht es in diesem Artikel. Wenn Sie lieber nicht sieben Tools zusammenkleben und die Infrastruktur selbst warten möchten, bietet Apidogs kostenloser Tarif plus seine CLI eine integrierte Alternative. Beides ist gültig; sie optimieren für unterschiedliche Dinge. Wenn Sie den CLI-Weg gehen, führt Sie die Installationsanleitung durch die Authentifizierung und die ersten Befehle.

Wie man wählt

Wählen Sie das passende Tool für die Aufgabe. Die meisten Entwickler verwenden mehrere davon zusammen: curl oder HTTPie zum Abrufen, jq zum Parsen, Hurl zum Testen, git zur Versionskontrolle von allem.

Die Faustregel: Greifen Sie zum quelloffenen Einzweck-Tool, wenn Sie die Infrastruktur selbst besitzen möchten, und zu einer integrierten Plattform, wenn Sie dies lieber nicht tun. Wenn Sie diesen Kompromiss über eine gesamte Toolchain abwägen, erklärt die Aufschlüsselung von Apidog als umfassende API-Entwicklungsplattform, was der integrierte Weg ersetzt.

Zusammenfassung

Open Source verdient seinen Platz im Terminal, indem es überprüfbar, selbst-hostbar und frei von Vendor Lock-in ist. curl, HTTPie, jq, gh, Hurl, cloudflared und git decken den Kern der API- und Backend-Entwicklung ab, und jedes davon ist eine Lizenz, die Sie lesen können, und ein Repository, das Sie forken können. Beginnen Sie mit den zwei oder drei, die zu Ihrem aktuellen Workflow passen, und fügen Sie den Rest hinzu, wenn Sie ihn benötigen.

Wenn Sie agentengesteuerte Workflows darauf aufbauen, gelten dieselben Terminal-First-Prinzipien, und strukturierte JSON-Ausgabe wird zum Bindegewebe; der Artikel über KI-Programmierassistenten für die API-Entwicklung geht dort tiefer. Und wenn die Wartung von sieben separaten Tools anfängt, sich wie eine eigene Aufgabe anzufühlen, dann laden Sie Apidog herunter und probieren Sie die Apidog CLI aus, um zu sehen, wie der integrierte Weg aussieht, bevor Sie sich festlegen.