DEV Community

Cover image for Beste leichtgewichtige CLI-Tools für API-Tests
Emre Demir
Emre Demir

Posted on • Originally published at apidog.com

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. Für schnelle Prüfungen im Terminal ist das unnötige Reibung: Sie möchten einen Befehl eingeben, die Antwort lesen und weitermachen. Leichte CLI-Tools stellen deshalb die Anfrage in den Mittelpunkt – nicht die Benutzeroberfläche.

Apidog noch heute ausprobieren

Leichtgewichtig bedeutet in diesem Kontext: kleine Installation, schneller Start, keine Pflichtkonfiguration für die erste Anfrage und terminalfreundliche Ausgabe. Das ist nicht zwingend die Frage, welches Tool die meisten Funktionen bietet oder Open Source ist, sondern welches im Alltag den geringsten Fußabdruck hat. Eine breitere Übersicht einschließlich gehosteter GUIs finden Sie in der Zusammenfassung der besten kostenlosen API-Test-Tools.

Dieser Beitrag zeigt acht CLI-Tools für REST- und HTTP-APIs – von einzelnen manuellen Requests bis zu wiederholbaren Tests und CI-Gates. Zu jedem Tool finden Sie:

  • einen Installationsbefehl,
  • einen direkt ausführbaren Einstieg,
  • den passenden Anwendungsfall,
  • sowie eine praktische Einschränkung.

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

Nicht jedes Terminal-Tool ist automatisch leichtgewichtig. Für diese Liste sind vier Kriterien entscheidend:

  1. Geringer Fußabdruck

    Idealerweise ein einzelnes Binary, eine pip-/npm-Installation oder ein npx-Befehl. Keine zusätzliche Infrastruktur und kein Daemon.

  2. Schneller Start

    Das Tool startet und sendet die Anfrage ohne lange Aufwärmphase. Kompilierte Rust- und Go-Binaries sind hier oft im Vorteil.

  3. Wenig oder keine Konfiguration

    Der erste Request soll ohne Konto, Projektdatei oder Login funktionieren. Konfiguration ist erst nötig, wenn Sie Abläufe speichern und wiederholen möchten.

  4. Terminal-native Ausgabe und Exit-Codes

    Ergebnisse müssen lesbar sein, sich an jq oder grep weiterleiten lassen und bei Fehlern einen Nicht-Null-Exit-Code liefern. Das ist entscheidend für CI.

Wenn Sie vor allem interaktive Clients vergleichen möchten, lesen Sie auch den Leitfaden zu curl-Alternativen für REST-API-Tests.

curl: die bereits installierte Basislinie

curl ist auf macOS, den meisten Linux-Distributionen und modernen Windows-Versionen häufig bereits verfügbar. Damit ist die leichteste Installation: keine Installation.

# Verfügbarkeit und Version prüfen
curl --version

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

Für eine lesbare JSON-Antwort kombinieren Sie curl mit jq:

curl -s https://httpbin.org/get | jq
Enter fullscreen mode Exit fullscreen mode

Am besten geeignet für: Einmalanfragen, Shell-Skripte und eingeschränkte Umgebungen, in denen Sie keine Tools installieren können.

Einschränkung: Header, Payloads und Assertions sind manuell. curl sendet Requests zuverlässig, ist aber kein Test-Runner. Für automatisierte Prüfungen müssen Sie Statuscodes und Response-Inhalte selbst auswerten.

HTTPie: curl für Menschen

HTTPie vereinfacht die Eingabe von Headern und JSON-Daten. Felder werden als key=value geschrieben, Zahlen mit :=, und die Ausgabe ist standardmäßig formatiert.

python -m pip install httpie
# Alternative auf macOS:
# brew install httpie

# Zeichenketten und Zahlen als JSON senden
http POST httpbin.org/post name=acme age:=24 plan=pro
Enter fullscreen mode Exit fullscreen mode

Header und Authentifizierung bleiben ebenfalls kompakt:

http GET https://httpbin.org/bearer \
  Authorization:"Bearer $API_TOKEN"
Enter fullscreen mode Exit fullscreen mode

Am besten geeignet für: Manuelles Erkunden von APIs mit gut lesbarer Ausgabe und weniger Flags als bei curl.

Einschränkung: HTTPie benötigt Python. Der Start ist damit meist langsamer als bei einem kompilierten Binary. Außerdem ist HTTPie primär ein Client, kein Assertions-Runner.

xh: HTTPie-Syntax als schnelles Binary

xh implementiert die HTTPie-ähnliche Syntax in Rust. Sie erhalten eine ähnliche Bedienung, aber mit schnellerem Start und ohne Python-Laufzeitumgebung.

brew install xh

# Alternative über Cargo
# cargo install xh --locked

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

Wenn Sie den entsprechenden curl-Befehl sehen möchten:

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

Am besten geeignet für: Entwickler, die HTTPie-Ergonomie wollen, aber ein einzelnes schnelles Binary bevorzugen.

Einschränkung: xh implementiert nicht jede HTTPie-Funktion und hat kein Plugin-System. Es bleibt ein manueller HTTP-Client und ersetzt keine Test-Suite.

Hurl: Klartext-Tests für CI

Hurl macht aus Requests wiederholbare Tests. Sie beschreiben Anfrage und erwartete Antwort in einer .hurl-Datei. Fehlgeschlagene Assertions erzeugen einen Nicht-Null-Exit-Code.

brew install hurl

# Alternative über Cargo
# cargo install --locked hurl
Enter fullscreen mode Exit fullscreen mode

Erstellen Sie eine Testdatei:

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

HTTP 200
[Asserts]
jsonpath "$.json.user" == "acme"
jsonpath "$.json.plan" == "pro"
EOF
Enter fullscreen mode Exit fullscreen mode

Führen Sie den Test aus:

hurl --test login.hurl
Enter fullscreen mode Exit fullscreen mode

In CI reicht derselbe Befehl:

- name: API-Smoketest
  run: hurl --test login.hurl
Enter fullscreen mode Exit fullscreen mode

Am besten geeignet für: Smoke-Tests, Vertragsprüfungen und versionierte HTTP-Tests, die im Pull Request lesbar bleiben sollen.

Einschränkung: Hurl ist HTTP-zentriert. Es ersetzt weder ein gRPC-Tool noch ein Lasttest-Tool. Komplexe Abläufe werden über mehrere .hurl-Dateien oder umfangreichere Testdefinitionen abgebildet.

Step CI: mehrstufige API-Workflows in YAML

Step CI ist für Workflows gedacht, in denen Requests voneinander abhängen: anmelden, Token extrahieren, mit Token einen zweiten Request senden und Ergebnisse prüfen. Es unterstützt REST, GraphQL, gRPC, tRPC und SOAP in YAML-basierten Workflows.

npm install -g stepci

stepci run workflow.yml
Enter fullscreen mode Exit fullscreen mode

Ein Workflow kann beispielsweise Schritte, Variablen und Assertions in einer Datei bündeln:

version: "1.1"
name: Login-Workflow
env:
  BASE_URL: https://example.com

tests:
  login:
    steps:
      - name: Anmelden
        http:
          url: ${BASE_URL}/login
          method: POST
          body:
            application/json:
              email: dev@example.com
              password: secret
Enter fullscreen mode Exit fullscreen mode

Am besten geeignet für: Teams, die deklarative, mehrstufige Flows lokal und in CI identisch ausführen möchten.

Einschränkung: Step CI ist ein Node-Paket und benötigt daher eine Node-Laufzeitumgebung. Prüfen Sie vor einer langfristigen CI-Einführung die aktuelle Aktivität des Repositories. Für die Einordnung in einen umfassenderen Plan siehe API-Teststrategien.

k6: Lasttests direkt aus dem Terminal

k6 beantwortet nicht primär die Frage „Ist diese Response korrekt?“, sondern „Hält der Service unter Last stand?“. Es ist ein Go-basiertes Binary; Tests schreiben Sie in JavaScript.

brew install k6

# Alternative über Docker:
# docker run grafana/k6
Enter fullscreen mode Exit fullscreen mode

Beispiel für einen kleinen Lasttest mit zehn virtuellen Nutzern:

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

Der Schwellenwert p(95)<500 fordert, dass 95 % der Requests unter 500 ms bleiben. Wird ein definierter Schwellenwert überschritten, beendet k6 den Lauf mit Code 99, was CI als Fehler behandeln kann.

Am besten geeignet für: Performance- und Lastprüfungen, die ohne Cluster direkt vom Laptop oder aus CI ausgeführt werden sollen.

Einschränkung: k6 ist kein Ersatz für einen manuellen API-Client oder eine vollständige funktionale Testsuite. Aussagekräftige Tests erfordern Kenntnisse der k6-JavaScript-API.

Newman: Postman-Sammlungen headless ausführen

Newman ist der CLI-Runner für Postman-Sammlungen. Wenn Ihr Team Requests und Tests bereits in Postman pflegt, kann Newman dieselben Sammlungen ohne GUI in CI ausführen.

npm install -g newman

# collection.json und staging.json aus Postman exportieren
newman run collection.json -e staging.json
Enter fullscreen mode Exit fullscreen mode

Beispiel für einen CI-Schritt:

- name: Postman-Collection ausführen
  run: newman run collection.json -e staging.json
Enter fullscreen mode Exit fullscreen mode

Newman gibt bei fehlgeschlagenen Tests einen Nicht-Null-Exit-Code zurück.

Am besten geeignet für: Teams, die bereits in Postman investieren und vorhandene Sammlungen automatisiert ausführen möchten.

Einschränkung: Newman ist an das Postman-JSON-Format gebunden und benötigt Node.js. Die Tests werden typischerweise weiterhin in der Postman-GUI erstellt.

Apidog CLI: visuell erstellte Szenarien headless ausführen

Die Apidog CLI ist der Terminal-Runner von Apidog. Das npm-Paket apidog-cli führt Test-Szenarien aus, die Sie zuvor visuell in Apidog erstellt haben.

Der praktische Ablauf:

  1. Erstellen Sie einen mehrstufigen Test im visuellen Editor.
  2. Definieren Sie Variablen, Extraktionen und Assertions.
  3. Öffnen Sie im Szenario den Tab CI/CD.
  4. Kopieren Sie den generierten apidog run-Befehl.
  5. Fügen Sie ihn in Ihre lokale Shell oder CI-Pipeline ein. 
npm install -g apidog-cli

apidog login --with-token <YOUR_TOKEN>

# Den konkreten Befehl im CI/CD-Tab des Szenarios kopieren
apidog run -t <scenario_id> -e <env_id> -r cli
Enter fullscreen mode Exit fullscreen mode

Der Reporter cli zeigt Schritt-für-Schritt-Ergebnisse und eine Zusammenfassung im Terminal:

apidog run -t <scenario_id> -e <env_id> -r cli
Enter fullscreen mode Exit fullscreen mode

Wenn Ihr CI-System JUnit-Ergebnisse verarbeiten soll, ergänzen Sie den Reporter:

apidog run -t <scenario_id> -e <env_id> -r cli,junit
Enter fullscreen mode Exit fullscreen mode

apidog run beendet sich mit 0, wenn alle Assertions erfolgreich sind, und mit einem Nicht-Null-Wert bei Fehlern. Dadurch können Sie den Befehl direkt als CI-Gate verwenden.

Am besten geeignet für: Teams, die komplexe Szenarien visuell erstellen und anschließend in CI, im Terminal oder durch Agenten headless ausführen möchten.

Einschränkung: Anders als curl oder xh ist die CLI an Szenarien gebunden, die in einem Apidog-Projekt gespeichert sind. Sie ist damit eine integrierte Plattformoption und kein reiner HTTP-Client.

Weitere Details finden Sie im vollständigen Apidog-CLI-Leitfaden, in der Apidog-run-Befehlsreferenz und in der Anleitung zum Testen einer REST-API über die Befehlszeile mit der Apidog CLI.

Wie man wählt

Tool Am besten geeignet für Installation Open Source? Hinweise
curl Einmalanfragen, Skripte vorinstalliert Ja (MIT/curl) Universell; Assertions sind DIY
HTTPie Lesbare manuelle Anfragen pip install httpie Ja (BSD-3) Freundliche Syntax; Python-Laufzeitumgebung
xh HTTPie-Gefühl, schneller brew install xh Ja (MIT) Einzelnes Rust-Binary
Hurl Klartext-HTTP-Tests brew install hurl Ja (Apache-2.0) --test steuert CI
Step CI Mehrstufige YAML-Flows npm i -g stepci Ja (MPL-2.0) REST/GraphQL/gRPC; Node-Laufzeitumgebung
k6 Last und Performance brew install k6 Ja (AGPL-3.0) JS-Skripte; Schwellenwerte können den Lauf fehlschlagen lassen
Newman Postman-Sammlungen in CI npm i -g newman Ja (Apache-2.0) Führt Postman-JSON headless aus
Apidog CLI Visuell erstellte Szenarien, headless ausgeführt npm i -g apidog-cli Nein (kostenloser Plan) Exit-Code-Gate; strukturiertes JSON

Als Faustregel:

  • Verwenden Sie curl oder xh, wenn Sie sofort einen Endpunkt prüfen möchten.
  • Verwenden Sie HTTPie, wenn Ihnen eine besonders lesbare manuelle Syntax wichtig ist.
  • Wechseln Sie zu Hurl, sobald Requests als versionierte Tests in CI laufen sollen.
  • Nutzen Sie Step CI für deklarative Workflows mit mehreren abhängigen API-Schritten.
  • Setzen Sie k6 ein, wenn Latenz, Durchsatz und Last die eigentlichen Fragen sind.
  • Verwenden Sie Newman, wenn die Tests bereits als Postman-Sammlungen existieren.
  • Wählen Sie Apidog CLI, wenn Sie Szenarien visuell erstellen und überall headless ausführen möchten.

Wenn Sie diese Optionen mit vollständig GUI-freien Abläufen vergleichen möchten, behandelt der Leitfaden zu headless API-Test-Tools das Ausführen von Tests ohne Benutzeroberfläche.

Wo sich leichtgewichtige Tools auszahlen

Leichte CLI-Tools lohnen sich immer dann, wenn eine GUI bremst:

  • beim Debugging direkt im Terminal,
  • in kurzlebigen CI-Runnern,
  • in Shell-Skripten,
  • bei reproduzierbaren Smoke-Tests,
  • oder wenn ein KI-Agent Tests ausführen und Exit-Codes auswerten soll.

curl und xh halten den manuellen Feedback-Loop kurz. Hurl und Step CI machen aus Ad-hoc-Requests wiederholbare Tests. k6 liefert Antworten zur Belastbarkeit. Newman führt vorhandene Postman-Tests aus.

Die Apidog CLI verbindet das visuelle Erstellen eines Tests mit der headless Ausführung. Sie erstellen ein Szenario einmal in Apidog, führen es anschließend mit apidog run lokal, in einer Pipeline oder über einen Agenten aus und verwenden den Exit-Code als Build-Gate. Laden Sie Apidog herunter, erstellen Sie ein Szenario und übernehmen Sie den generierten apidog run-Befehl in Ihre CI-Konfiguration.

Top comments (0)