Beste leichtgewichtige CLI-Tools für API-Tests

Die meisten API-Test-Tools verlangen, dass Sie ein Fenster öffnen, sich anmelden und in einem Arbeitsbereich herumklicken, bevor Sie eine einzige Anfrage senden können. Das ist für einen ersten Blick in Ordnung. Für das Terminal, wo Sie eine Zeile eingeben, die Antwort lesen und weitermachen möchten, ist es die falsche Form. Leichte Befehlszeilen-Tools kehren die Reihenfolge um: Das Tool tritt in den Hintergrund, und die Anfrage ist die gesamte Interaktion.

Leichtgewichtig bedeutet hier etwas Spezifisches. Eine kleine Installation, oft ein einzelnes Binary oder ein schnelles npx. Schneller Start, sodass das Ansprechen eines Endpunkts sofort erfolgt. Wenig oder keine Konfiguration für die erste Anfrage. Terminal-optimierte Ausgabe, die Sie in jq oder grep leiten können. Dies ist eine andere Frage als „welches Tool ist Open Source“ oder „welches hat die meisten Funktionen“. Es geht um den Fußabdruck und die Reibung. Eine breitere Übersicht, die auch gehostete GUIs abdeckt, finden Sie in der Zusammenfassung der besten kostenlosen API-Test-Tools.

Im Folgenden finden Sie acht leichte CLI-Tools zum Testen von REST- und HTTP-APIs, grob geordnet von den kleinsten und manuellsten bis zu jenen, die vollständige Testsuiten in CI ausführen. Jeder Eintrag enthält einen echten Installationsbefehl, einen Befehl, der die Funktionsweise zeigt, wofür er am besten geeignet ist, und eine ehrliche Einschränkung. Das letzte Tool, die Apidog CLI, ist das leichte Binary, das die Szenarien ausführt, die Sie visuell erstellen, und eine Pipeline anhand seines Exit-Codes steuert.

Was macht ein CLI-Tool für API-Tests „leichtgewichtig“?

Viele Tools laufen in einem Terminal. Nicht alle von ihnen fühlen sich leicht an. Für diese Liste qualifiziert sich ein Tool nach vier Punkten:

• Geringer Fußabdruck. Ein einzelnes Binary, eine pip-/npm-Installation oder ein npx-Einzeiler. Keine Laufzeitumgebung, die Sie zuerst einrichten müssen, idealerweise kein Daemon.
• Schneller Start. Das Tool startet und sendet die Anfrage ohne Aufwärmphase. Rust- und Go-Binaries sind hier im Vorteil; alles, was eine schwere Laufzeitumgebung bootet, verliert.
• Geringe oder keine Konfiguration. Sie können die erste Anfrage ohne Projektdatei, Konto oder Anmeldung senden. Die Konfiguration ist optional, falls Sie speichern und wiederholen möchten.
• Terminal-native Ausgabe. Die Ergebnisse werden in einer Form ausgegeben, die Sie auf einen Blick lesen und in einen anderen Befehl weiterleiten können. Exit-Codes bedeuten etwas, sodass CI sie als Kontrollpunkt nutzen kann.

Die Tools beginnen mit den ersten drei; die letzten beiden stützen sich auf den vierten, denn dort verdient ein leichtgewichtiges Binary seinen Platz in einer Pipeline. Wenn Sie die interaktive, manuelle Seite des Endpunkt-Ansprechens detaillierter betrachten möchten, bietet der Leitfaden curl-Alternativen für REST-API-Tests tiefere Einblicke in manuelle Clients.

curl: die bereits installierte Basislinie

curl ist das Tool, das Sie mit ziemlicher Sicherheit bereits haben. Es wird mit macOS, den meisten Linux-Distributionen und modernen Windows-Versionen ausgeliefert, daher ist die leichteste Installation gar keine Installation. Es unterstützt HTTP, HTTPS und eine lange Liste weiterer Protokolle und ist die Referenz, an der sich jeder andere Client misst.

# Bereits auf Ihrem Computer; Version prüfen
curl --version

# JSON POSTEN und nur den HTTP-Status ausgeben
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"user":"acme","plan":"pro"}'

Am besten geeignet für: schnelle Einmalanfragen, Skripte und jede Umgebung, in der Sie nichts Neues installieren können. Ehrliche Einschränkung: Die Ergonomie ist veraltet. Sie setzen Header manuell, JSON wird nicht hübsch formatiert, und das Überprüfen einer Antwort bedeutet, sie in jq zu leiten und einen Exit-Code selbst zu überprüfen. Es sendet und zeigt; es testet nicht.

HTTPie: curl für Menschen

HTTPie macht die gleichen Anfragen wie curl, aber mit einer Syntax, die für Menschen gemacht ist. Der Befehl ist http, Header und JSON-Felder sind einfache key=value-Paare, und die Ausgabe ist standardmäßig farbig und formatiert. Es ist in Python geschrieben, benötigt also eine Python-Laufzeitumgebung, was es schwerer als ein einzelnes Binary macht, aber dennoch eine Ein-Zeilen-Installation ermöglicht.

python -m pip install httpie   # oder: brew install httpie

# JSON POSTEN: age:=24 sendet eine Zahl, name= sendet eine Zeichenkette
http POST httpbin.org/post name=acme age:=24 plan=pro

Am besten geeignet für: das manuelle Erkunden einer API, wenn Sie eine lesbare Ausgabe ohne Flags wünschen. Ehrliche Einschränkung: Der Python-Start ist merklich langsamer als bei einem kompilierten Binary, und die Installation in einem sauberen System bedeutet, Python zu installieren, falls es nicht vorhanden ist. Wie curl ist es ein Client, kein Test-Runner; Sie lesen die Antwort, Sie überprüfen sie nicht.

xh: HTTPies Geschwindigkeit in einem einzigen Binary

xh implementiert HTTPies benutzerfreundliche Syntax in Rust neu und wird als ein statisch verknüpftes Binary ausgeliefert. Sie erhalten die gleiche key=value-Ergonomie und farbige Ausgabe, mit schnellerem Start und nichts weiter zu installieren als das Binary selbst. Es unterstützt HTTP/2 und kann sogar den äquivalenten curl-Befehl mit --curl ausgeben.

brew install xh   # oder: cargo install xh --locked

# Gleiche Syntax wie HTTPie, schnellerer Start
xh POST httpbin.org/post name=acme age:=24 plan=pro

Am besten geeignet für: Entwickler, die das HTTPie-Gefühl mögen, aber ein einzelnes, schnelles Binary ohne Laufzeitumgebung wünschen. Ehrliche Einschränkung: Es implementiert nicht jede HTTPie-Funktion und es gibt kein Plugin-System. Es ist jünger als HTTPie, daher ist das Ökosystem darum kleiner. Immer noch ein Client, keine Assertions-Engine.

Hurl: Klartext-Tests, die in CI laufen

Hurl ist der Punkt, an dem diese Liste von „eine Anfrage senden“ zu „eine Antwort testen“ übergeht. Es führt HTTP-Anfragen aus, die in einer Klartext-.hurl-Datei geschrieben sind, und überprüft die Ergebnisse. Es ist in Rust geschrieben, wird unter der Haube von libcurl angetrieben und wird als einzelnes Binary ohne Laufzeitumgebung ausgeliefert. Tests lesen sich fast wie die Anfragen selbst, was sie in einem Pull Request leicht überprüfbar macht.

brew install hurl   # oder: cargo install --locked hurl

cat > login.hurl <<'EOF'
POST https://httpbin.org/post
{ "user": "acme", "plan": "pro" }

HTTP 200
[Asserts]
jsonpath "$.json.user" == "acme"
EOF

hurl --test login.hurl   # nicht-null Exit bei fehlgeschlagener Assertion

Am besten geeignet für: vertragsbasierte Prüfungen und Smoke-Tests, die Sie als lesbaren Text in der Versionskontrolle speichern. Das --test-Flag macht es zu einem sauberen CI-Gate; eine fehlgeschlagene Assertion gibt einen Nicht-Null-Exit-Code zurück. Ehrliche Einschränkung: Es ist HTTP-zentriert, daher wird es kein gRPC steuern oder echte Last erzeugen. Komplexe Abläufe bedeuten mehr .hurl-Dateien statt einer Skriptsprache.

Step CI: eine YAML-Datei für einen mehrstufigen Workflow

Step CI führt API-Workflows aus, die in einer einzigen YAML-Datei beschrieben sind. Es deckt REST, GraphQL, gRPC, tRPC und SOAP in einem Workflow ab und kann gegen ein OpenAPI-Schema validieren. Sie installieren es über npm und führen dieselbe Datei lokal und in CI aus. Es lässt sich gut lesen, wenn ein Test wirklich eine Abfolge ist: Anmelden, einen Token erfassen, diesen beim nächsten Aufruf verwenden, das Ergebnis überprüfen.

npm install -g stepci

# workflow.yml beschreibt Schritte, Erfassungen und Prüfungen
stepci run workflow.yml

Am besten geeignet für: Teams, die eine deklarative Datei wünschen, die einen mehrstufigen API-Flow beschreibt, der auf einem Laptop und in einer Pipeline identisch ausgeführt wird. Ehrliche Einschränkung: Es ist ein Node-Paket, daher ist es schwerer als ein Rust- oder Go-Binary und es bringt eine Laufzeitumgebung mit sich. Die Veröffentlichungsfrequenz hat sich verlangsamt, prüfen Sie daher die jüngsten Aktivitäten des Repositories, bevor Sie eine Pipeline darauf aufbauen. Wie diese Teile in einen umfassenderen Testplan passen, erfahren Sie unter API-Teststrategien.

k6: Leichtgewichtiger Lasttest vom Terminal aus

k6 beantwortet eine andere Frage: nicht „ist diese Antwort korrekt“, sondern „hält sie unter Last stand“. Es ist in Go geschrieben, wird als einzelnes statisches Binary ausgeliefert, und Skripte sind einfaches JavaScript. Es ist für minimalen Ressourcenverbrauch ausgelegt, sodass Sie echten Traffic von einem Laptop aus pushen können. Schwellenwerte machen einen Lasttest zu einem Pass/Fail-Gate; wird einer überschritten, beendet k6 mit Code 99, was eine Pipeline als Fehler interpretiert.

brew install k6   # oder über Docker ausführen: docker run grafana/k6

cat > load.js <<'EOF'
import http from 'k6/http';
import { check } from 'k6';
export const options = {
  vus: 10, duration: '30s',
  thresholds: { http_req_duration: ['p(95)<500'] },
};
export default function () {
  const res = http.get('https://httpbin.org/get');
  check(res, { 'status is 200': (r) => r.status === 200 });
}
EOF

k6 run load.js

Am besten geeignet für: Performance- und Lastprüfungen, die Sie skripten und in CI ausführen möchten, ohne einen Cluster aufzubauen. Ehrliche Einschränkung: Es ist ein Last-Tool, kein funktionaler Test-Client; Sie würden es nicht verwenden, um eine einzelne Antwort zu überprüfen. Das Schreiben aussagekräftiger Szenarien bedeutet, seine JavaScript-API zu lernen.

Newman: eine Postman-Sammlung headless ausführen

Newman ist der Kommandozeilen-Runner für Postman-Sammlungen. Wenn Ihr Team bereits Anfragen und Tests in Postman erstellt, führt Newman genau diese Sammlung von einem Terminal ohne GUI aus, was Sie in CI benötigen. Sie exportieren die Sammlung (und optional eine Umgebung) als JSON und weisen Newman darauf hin.

npm install -g newman

# collection.json aus Postman exportiert; -e übergibt eine Umgebung
newman run collection.json -e staging.json

Am besten geeignet für: Teams, die in Postman investiert sind und ihre bestehenden Sammlungen headless in einer Pipeline ausführen möchten. Newman gibt einen Nicht-Null-Exit-Code zurück, wenn ein Test fehlschlägt, sodass er CI sauber steuert. Ehrliche Einschränkung: Es ist ein Node-Paket und führt nur Sammlungen im Postman-Format aus, daher ist es am nützlichsten, wenn Sie bereits in diesem Ökosystem sind. Es führt Tests aus, die jemand in einer GUI erstellt hat; die Erstellung erfolgt immer noch dort.

Apidog CLI: Führen Sie die von Ihnen erstellten Szenarien aus, steuern Sie CI über den Exit-Code

Die Apidog CLI ist das leichtgewichtige Ende von Apidog. Es ist ein npm-Paket, apidog-cli, das die Test-Szenarien, die Sie visuell in Apidog entworfen haben, direkt von einem Terminal aus ausführt. Der Teil der Testerstellung bleibt in der GUI, wo das Verketten von Anfragen, das Extrahieren von Variablen und das Schreiben von Assertions schnell ist; die CLI ist das kleine Stück, das eines dieser Szenarien headless ausführt und Ihnen einen Exit-Code zurückgibt. Apidog ist nicht Open Source, aber sein kostenloser Plan plus diese CLI bietet Ihnen eine integrierte Alternative zum Zusammenfügen separater Clients, Runner und Last-Tools.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>

# Kopieren Sie den genauen Befehl aus dem CI/CD-Tab Ihres Szenarios
apidog run -t <scenario_id> -e <env_id> -r cli

Sie müssen die Szenario- und Umgebungs-IDs nicht erraten. Öffnen Sie Ihr Testszenario in Apidog, gehen Sie zum CI/CD-Tab und kopieren Sie den generierten apidog run-Befehl mit den bereits ausgefüllten IDs. Der -r cli-Reporter gibt ein Schritt-für-Schritt-Ergebnis und eine Zusammenfassung im Terminal aus; fügen Sie -r cli,junit hinzu, wenn ein CI-Dashboard die Ergebnisse parsen muss. Wie die oben genannten Tools beendet apidog run mit 0, wenn alle Assertions erfolgreich sind, und mit einem Nicht-Null-Wert, wenn etwas fehlschlägt, sodass eine Pipeline es als sauberes Gate behandelt. Seine Ausgabe ist strukturiertes JSON mit agentHints.nextSteps, was es auch einem KI-Code-Agenten leicht macht, es auszuführen und zu lesen.

Am besten geeignet für: Teams, die komplexe, mehrstufige Szenarien in einem visuellen Editor erstellen, aber headless in CI oder von einem Agenten ausführen möchten. Ehrliche Einschränkung: Im Gegensatz zu curl oder xh ist es an Szenarien gebunden, die Sie in einem Apidog-Projekt speichern, daher ist es die integrierte Plattformoption, kein reiner HTTP-Client. Für den vollständigen Befehlssatz siehe den Apidog CLI vollständigen Leitfaden, die Apidog run Befehlsreferenz und die Schritt-für-Schritt-Anleitung zum Testen einer REST-API über die Befehlszeile mit der Apidog CLI.

Wie man wählt

Das richtige Tool hängt davon ab, wie weit Sie über „eine Anfrage senden“ hinausgehen müssen.

Beginnen Sie oben für manuelle Arbeiten. Greifen Sie zu curl oder xh, um einen Endpunkt anzusteuern. Wechseln Sie zu Hurl, wenn Sie diese Prüfungen in der Versionskontrolle ausführen möchten. Ziehen Sie k6 heran, wenn es um Last geht, und Newman, wenn Ihre Tests bereits in Postman existieren. Wählen Sie die Apidog CLI, wenn Sie lieber ein komplexes Szenario in einem Editor erstellen und es überall sonst headless ausführen möchten. Wenn Sie diese Optionen gegen einen vollständig GUI-freien Workflow abwägen, behandelt der Leitfaden für headless API-Test-Tools das Ausführen von Tests ganz ohne Benutzeroberfläche.

Wo sich leichtgewichtige Tools auszahlen

Leichtgewichtige CLI-Tools sind dann von Vorteil, wenn eine GUI Sie ausbremst: wenn Sie tief in einem Terminal arbeiten, wenn ein Test in CI ohne menschliches Eingreifen ausgeführt werden muss und zunehmend, wenn ein KI-Agent die Überprüfung für Sie durchführt. curl und xh halten den manuellen Kreislauf eng. Hurl und Step CI verwandeln Ad-hoc-Anfragen in wiederholbare Tests. k6 beantwortet die Lastfrage. Newman führt aus, was Sie bereits in Postman erstellt haben.

Die Apidog CLI schließt die Lücke zwischen dem Erstellen eines Tests und dessen Ausführung an beliebiger Stelle. Sie entwerfen das Szenario einmal in Apidog, dann führt apidog run es von einem Terminal, einer Pipeline oder einem Agenten aus, und der Exit-Code entscheidet, ob der Build grün bleibt. Laden Sie Apidog herunter, erstellen Sie ein Szenario und fügen Sie den apidog run-Befehl in Ihre CI-Konfiguration ein, um zu sehen, wie sich der gesamte Kreislauf schließt.