Hurl – textbasiertes Tool für HTTP-Anfragen und -Tests auf der Kommandozeile

 (github.com/Orange-OpenSource)
27 Punkte von GN⁺ 2025-06-21 | 3 Kommentare | Auf WhatsApp teilen
  • Open-Source-Kommandozeilen-Tool, das HTTP-Anfragen in einem einfachen Textdateiformat ausführt und mehrere Anfragen verketten sowie Werte extrahieren und Abfragen/Validierungen für Response-Body und Header durchführen kann
  • Unterstützt verschiedene APIs und HTML/XML/JSON-basierte Anfragen wie REST, SOAP und GraphQL und eignet sich sowohl für Datenabfragen als auch für HTTP-Session-Tests
  • Ermöglicht Request-Chaining, Value-Capturing und vielfältige Validierungen wie Statuscode, Header und Body und ist vorteilhaft für CI/CD-Integration und Automatisierung mit Junit-, TAP-, HTML- und JSON-Reports
  • Wird als einzelne ausführbare Datei, implementiert in Rust, verteilt, ist einfach zu installieren und bietet intern mit der libcurl-Engine hohe Geschwindigkeit und starke Protokollkompatibilität
  • Gilt gegenüber konkurrierenden Tools als modernes Tool zur HTTP-Testautomatisierung mit prägnanter Syntax, Erweiterbarkeit und vielfältigen Funktionen
  • Als Community-getriebenes Open Source wird es dank seines intuitiven und erweiterbaren textbasierten Formats sowohl von Entwicklern als auch im DevOps-Bereich vielseitig genutzt

What's Hurl?

  • Hurl ist ein Tool, mit dem sich HTTP-Anfragen in einem klaren und intuitiven Textformat schreiben und auf der Kommandozeile ausführen lassen
  • Mehrere Anfragen können kettenartig verbunden werden; außerdem lassen sich Werte aus Responses extrahieren oder mit verschiedenen Abfragen (Header, Body, Statuscode usw.) komplexe HTTP-Szenarien testen
  • Basierend auf der libcurl-Engine, dadurch zuverlässig und mit Unterstützung für moderne Protokolle wie IPv6 und HTTP/3
  • Unterstützt Datenabfragen, Szenariotests und Performance-Messungen (z. B. Response-Zeiten)
  • Optimiert für die Erzeugung von Reports (Junit, TAP, HTML usw.) und die Integration in CI/CD-Pipelines
  • Unterstützt verschiedene APIs wie REST, SOAP, GraphQL, HTML, XML und JSON sowie auch Body-Parsing (z. B. XPath, JSONPath)
  • Im Vergleich zu anderen HTTP-Testtools (z. B. Postman, curl) sind dies wichtige Stärken von Hurl:
    • Kann als Plain Text geschrieben werden und ist dadurch gut für Versionsverwaltung und Zusammenarbeit geeignet
    • Bietet eine einzelne leichtgewichtige Binärdatei, geschrieben in Rust, ohne zusätzliche Runtime
    • Baut auf derselben Netzwerk-Engine wie curl (libcurl) auf und bietet dadurch Zuverlässigkeit und Unterstützung für viele Protokolle
    • Unterstützt verschiedene Formate wie REST, SOAP, GraphQL und HTML und ermöglicht komplexe Szenario-Setups
    • Einfache Integration mit CI/CD, Testautomatisierung und detaillierten Reports (JUnit, HTML, TAP usw.)

Zusammenfassung der Hauptfunktionen

  • Grundlegende Funktionsweise

    • Mehrere HTTP-Anfragen werden nacheinander in einer Hurl-Datei (.hurl) definiert und ausgeführt
    • Aus der Response jeder Anfrage können Werte extrahiert, Bedingungen validiert und Daten an die nächste Anfrage weitergegeben werden
    • Unterstützt verschiedene Formate wie REST/JSON, SOAP/XML, GraphQL und HTML

  • Chaining und Variablenverwendung

    • Mehrere Anfragen können in einer Datei als Kette geschrieben werden
    • Mit der Captures-Syntax lassen sich Werte aus Responses extrahieren und in späteren Anfragen als Variablen einsetzen
    • Datenextraktion und -verwendung über XPath, JSONPath, reguläre Ausdrücke und Body-Strukturen

  • Verschiedene Request- und Validierungsmethoden

    • Unterstützt die Konfiguration verschiedener Request-Spezifikationen wie Query-Parameter, Header und Authentifizierung
    • Mit der Syntax [Asserts] oder impliziter Syntax lassen sich Statuscode, Body, Header, Cookies, Response-Zeit, Hashes usw. validieren
    • Mit XPath und JSONPath können auch REST-/GraphQL-/SOAP- und HTML-Inhalte getestet werden
    • Unterstützt Multi-Value-Validierung, Response-Body-/Hash-/Zertifikatseigenschaften, Request-/Response-Verzögerungen und die Verarbeitung binärer Daten

  • Test-Reports und Automatisierungsintegration

    • Ausführungsergebnisse können als Reports in verschiedenen Formaten wie Text, HTML, JUnit, TAP und JSON ausgegeben werden
    • Lässt sich einfach in CI/CD-Pipelines integrieren

  • Erweiterte Steuerung und nützliche Funktionen

    • Datenübergabe zwischen Anfragen (Capturing und Variabilisierung)
    • Funktionen zur Erzeugung dynamischer Daten (newUuid, newDate usw.)
    • Anpassbare Optionen pro Anfrage
    • Polling/Wiederholungen, Request-Delays, Skip, Maskierung geheimer Werte (redact)
    • Unterstützt dieselben Optionen wie curl (curl-Optionen können direkt verwendet werden)
    • Integrierte Cloud-spezifische Funktionen wie AWS Sigv4-Authentifizierung

Anwendungsbeispiele

  • Einfache GET-/POST-Anfragen und mehrstufiges Request-Chaining lassen sich in einer einfachen Textdatei definieren
    • sample.hurl schreiben und mit dem Befehl $ hurl sample.hurl alle enthaltenen Anfragen gesammelt ausführen
  • Beispiel: 
      GET https://example.org  
  HTTP 200  
  [Captures]  
  csrf_token: xpath "string(//meta[@name='_csrf_token']/@content)"  

  POST https://example.org/login?user=toto&password=1234  
  X-CSRF-TOKEN: {{csrf_token}}  
  HTTP 302
  • Möglich sind Tests mehrerer API-Endpunkte und der Vergleich von Response-Werten, die Verwendung verketteter Werte (z. B. Tokens) sowie die Validierung von Statuscodes, Headern und Body-Daten

Typische Einsatzszenarien

  • Tests für verschiedene APIs wie REST, GraphQL, HTML, JSON und SOAP
  • Extraktion und Wiederverwendung von Werten wie CSRF-Tokens sowie Authentifizierungs- und Autorisierungsdaten
  • Präzise Validierung von Statuscodes, Headern, Body-Daten, Cookies und SSL-Zertifikaten
  • Automatisierung und Monitoring realer Service-Szenarien (von Login bis Geschäftsablauf usw.)
  • Unterstützt mehrere Plattformen und verschiedene Installationsmethoden (Linux, macOS, Windows, Docker, npm, Cargo usw.)

Wichtige CLI-Optionen

  • --test: Testmodus (Ausgabe von Zusammenfassung und Report)
  • --report-html, --report-json, --report-junit, --report-tap: Unterstützung für verschiedene Report-Formate
  • --parallel, --jobs N: Parallele Ausführung
  • --retry, --retry-interval: Automatische Wiederholungen/Wartezeit
  • -u, --user: Eingabe von Authentifizierungsdaten
  • --variable, --variables-file: Variablen festlegen
  • -o, --output: Response-Datei speichern
  • --json: Ausführungsergebnis im JSON-Format ausgeben

Installation

  • Installation über Homebrew, apt, yum, pacman, cargo, choco, scoop, Docker, npm usw. möglich
  • Da es sich um eine einzelne Binärdatei handelt, ist keine zusätzliche Runtime erforderlich
  • Beispiel: 
    brew install hurl
    oder 
    cargo install --locked hurl

Vorteile gegenüber konkurrierenden Tools

  • Gegenüber GUI-Tools wie Postman oder Insomnia besser geeignet für textbasierte Workflows, Versionsverwaltung und CI/CD-Integration
  • Gegenüber curl stärker auf Tests, Szenarioausführung, Validierung und Report-Automatisierung spezialisiert
  • Niedrigere Lernkurve dank eines intuitiven eigenen Formats statt komplexer DSLs wie YAML oder JSON

Verwandte Beiträge

3 Kommentare

 
seunggi 2025-07-04

Bruno – ein schneller, Git-freundlicher Open-Source-API-Client (Postman-Alternative)
https://de.news.hada.io/topic?id=13730
 
xguru 2025-06-21

Hurl 4.0.0 Release
Vor 2 Jahren war es 4.0, inzwischen ist bereits 6.1.1 erschienen.
 
GN⁺ 2025-06-21
Hacker-News-Kommentare

  • Ich habe in den letzten Monaten angefangen, hurl zu benutzen
    Mir gefällt sehr, dass man sowohl den Test-Suite-Modus als auch den Modus für einzelne Aufrufe verwenden kann
    Ich nutze es, um in CI eine Test-Suite für HTTP-Anfragen auszuführen
    Ich finde, die Konfigurationssprache mit ihren Blöcken ist nicht besonders intuitiv, und die Dokumentation zu den unterstützten Assertions wirkt etwas knapp
    Insgesamt liefert das Tool selbst aber einen großen Mehrwert
    Bei POC-Arbeiten habe ich angefangen, Schnittstellentests damit zu schreiben, und festgestellt, dass dieser Ansatz LLM-basierte Entwicklung unterstützen kann
    Dadurch, dass die Tests direkt an den HTTP-Methoden geschrieben werden, bleiben Tests und Implementierung im Verlauf der Projektentwicklung flexibler voneinander getrennt
    Diese Trennung sorgt auch dafür, dass die Grenze zwischen Schnittstelle und Implementierung klarer wird
    Vor der Einführung von hurl habe ich Tests mit dem Test-Framework der jeweiligen Service-Sprache geschrieben, aber mit hurl-basierten Tests hält man die „Client-Perspektive“ strikt ein
    Ohne Dinge wie Backdoor-Datenzugriff sind Schnittstelle, Tests und Implementierung sauber voneinander getrennt, was ein gutes Gefühl gibt

    • Ich bin der Entwickler von hurl
      Danke für das Feedback
      Als ich vor 6 bis 7 Jahren mit der ersten Entwicklung angefangen habe, habe ich erst JSON und dann YAML ausprobiert, war aber nach und nach davon überzeugt, ein eigenes neues Dateiformat zu entwerfen
      Ich verstehe gut, dass sich das aus Nutzersicht ungewohnt anfühlen kann
      Ich habe versucht, für einfachere Anwendungsfälle auch eine einfachere Syntax zu verwenden, aber perfekt ist das vielleicht nicht
      Was die Dokumentation angeht, freue ich mich sehr über Hinweise auf Mängel oder Verbesserungspotenzial und hoffe, sie weiter verbessern zu können

  • Hurl ist wirklich ein großartiges Tool
    Als ich einmal einen in Python geschriebenen Webservice nach Rust portiert habe, waren strenge Tests der öffentlichen API eine große Hilfe
    Dank einer sprachunabhängigen Integrations-Testumgebung konnte ich die API oder Website unverändert lassen und nur das Backend austauschen
    Bei der Nutzung von Hurl mit Rust gibt es noch einen besonderen Vorteil
    Man kann es mit cargo test integrieren und die hurl-Bibliothek direkt verwenden, wobei sich .hurl-Dateien unverändert wiederverwenden lassen
    Demo: https://github.com/perrygeo/axum-hurl-test

  • Ich habe im September 2023 angefangen, Hurl zu verwenden
    Früher habe ich Test-Suites über Runscope ausgeführt, aber es war extrem unpraktisch, dass Änderungen nicht versioniert wurden
    Nach etwas Vorarbeit bin ich auf Hurl umgestiegen und habe Runscope aufgegeben
    Jetzt kann ich auf einen Blick sehen, wer wann warum was geändert hat, und bin sehr zufrieden damit

    • Ich habe es wirklich gehasst, dass Änderungen in Runscope nicht versioniert wurden
      Unser Team hat auch versucht, das Problem zu lösen, und dabei hat das Projekt an Tempo verloren

  • Ich finde das Konzept an sich gut, frage mich aber, „warum sollte ich das benutzen?“
    Ich entwickle mit Django, und die im Framework eingebauten Testfunktionen sind bereits sehr umfangreich
    Ein Tool einzuführen, das mein eigenes Backend nicht kennt und nur von außen darauf zugreift, scheint mir eher zusätzlichen Synchronisationsaufwand zu erzeugen
    Man kann dann auch nicht einfach direkt in den Debugger springen, wenn etwas seltsam ist
    Es gibt zwar die Logik, Testcode und Backend-Code klar zu trennen, aber praktisch erhöht das die Wartungskosten eher
    Am Ende müsste man die native Test-Suite ja trotzdem ausführen, daher fühlt es sich seltsam an, mehrere externe Tools parallel zu nutzen
    Allerdings könnte es sinnvoll sein, wenn man prüfen will, wie generisch eine API tatsächlich funktioniert

    • Über die Frage, warum man ein Tool verwenden sollte, das das eigene Backend nicht kennt und nur mehr Synchronisationsaufwand erzeugt, habe ich auch viel nachgedacht
      Ich habe hurl selbst nicht benutzt, aber schon mehrfach sprachunabhängige Werkzeuge zum Testen von APIs verwendet und entwickle gerade auch selbst eines
      Warum solche Tools attraktiv wirken:

      • Dass sie die interne Implementierung nicht kennen, ist gerade ein Vorteil
        Weil nur Input und Output geprüft werden, hängen sie nicht von der internen Logik ab
      • Sie sind sprachunabhängig und lassen sich deshalb mit anderen Teams teilen oder anstelle einer OpenAPI-Spezifikation wie Dokumentation nutzen
      • Sie testen den API-Vertrag selbst und lassen sich deshalb auch bei großen Migrationen wiederverwenden
        Wenn man zum Beispiel eine öffentliche API von Perl nach Go migriert, kann man die bestehende Perl-API als Nicht-Regressions-Test verwenden und dieselben Tests unverändert gegen die Go-API laufen lassen, was das Vertrauen erhöht
      • Wenn Entwickler solche Tests schreiben, nehmen sie vorübergehend die Perspektive der API-Konsumenten ein und konnten dadurch bessere Tests mit höherer Qualität schreiben

    • Man kann es als Alternative zu Produkten wie Postman sehen
      Man muss nicht extra ein schwergewichtiges, auf Electron basierendes Fenster öffnen, nur um ein paar HTTP-Anfragen zu testen
      Es liegt irgendwo zwischen curl-Skripten und Postman und ist ideal für Leute, die zugleich Leichtgewichtigkeit und Komfort wollen

    • Wir haben Hurl bei einer Migration von einem ktor-Webserver zu Spring-Boot-basiertem Code im Java/Kotlin-Stack genutzt
      Dadurch konnten wir eine Test-Suite auf Spezifikationsebene unabhängig vom Server-Stack betreiben, was den Umstieg sehr reibungslos gemacht hat
      Außerdem verwenden wir Docker-Images in Produktion, und statt eines Tools, das zu stark an die Implementierung gebunden ist, konnten wir mit Hurl Integrations-Tests sehr leichtgewichtig und unabhängig halten

  • Der Beispielbereich (https://github.com/Orange-OpenSource/hurl?tab=readme-ov-file#samples) wirkt sehr überzeugend auf Leute, die die Vorteile des Tools in fünf Minuten erfassen wollen und dazu neigen, sich früh ein Urteil zu bilden
    Ich bin selbst manchmal so, und es ist wirklich beeindruckend

  • Ich bin Maintainer von Hurl
    Fragen oder Feedback sind jederzeit willkommen

    • Ein Muster, das ich zusammen mit vielen Entwicklern in meinem Umfeld häufig nutze: Wir schreiben Tests als ".http"-Dateien, die sich über IDE-Erweiterungen in VS Code oder IDEA ausführen lassen
      Ein Beispielformat ist

      POST http://localhost:8080/api/foo
Content-Type: application/json
{ "some": "body" }

      Danach vergleichen wir die Ausgabe 1:1 mit einer Datei namens "expected.json" und führen so Integrationstests durch
      Diese Dateien führen wir mit cURL und speziell geschriebenen bash-Skripten aus, vergleichen die Ergebnisse mit jq und protokollieren Erfolg oder Fehler in der Konsole
      Mich würde interessieren, ob man mit Hurl auf ähnliche Weise beispielhafte HTTP-Anfragen und erwartete Ergebnisse auf Basis von JSON-Dateien direkt in der IDE definieren kann
      Und ich frage mich auch, ob Hurl mehrere Dateien in einem Ordner automatisch ausführen kann

    • Hurl ist unterschätzt, weil man damit Test-Suites auf HTTP-Ebene schön und wartbar schreiben kann
      Danke, dass du so ein Tool entwickelt hast

    • Ich bin sehr zufrieden mit der Namenswahl Hurl
      Wirklich gutes Gespür der Entwickler

    • Ich habe Hurl eine Zeit lang verwendet und auch selbst dazu beigetragen
      Mich würde interessieren, wie es mit einer möglichen include-Funktion aussieht

    • Danke, dass ihr das Projekt kontinuierlich pflegt
      Mich würde interessieren, wie ihr die Vision und Zukunft von Hurl in zwei Jahren seht

  • Ich habe mich von diesem Projekt stark inspirieren lassen und selbst ein HTTP-Test-Tool entworfen
    Wir mussten Hunderte von Tests schnell parallel ausführen, und wenn dir Hurl gefällt, könnte auch ein Tool namens Nap interessant sein

    • Mich würde interessieren, ob Syntax und Inhalt der Konfiguration mit Hurl identisch sind oder worin die Unterschiede liegen
      Falls es eine Seite gibt, die die Unterschiede übersichtlich zusammenfasst, würde ich mich über einen Hinweis freuen

  • Sieht interessant aus
    Ich habe ursprünglich lange Vscode-restclient verwendet, steige für Skripting und CLI in letzter Zeit aber eher auf httpyac um
    Ich werde mir Hurl auch ansehen, um zu prüfen, ob es zu meinen Anforderungen passt
    Ein Problem, das mich bei Test-Tools stört, ist, dass es für .http-Dateien noch keinen Standard gibt, um das Ergebnis einer Anfrage als Eingabe für die nächste zu referenzieren
    Alle drei Tools, die ich bisher benutzt habe, machen das unterschiedlich

    • hurl verwendet [Captures]

    • Vscode-restclient referenziert den Namen der Anfrage in einer Variablendeklaration

    • httpyac nutzt die @ref-Syntax
      Weil jede Syntax anders ist, bricht das in anderen Tools, sobald man etwas für eines davon schreibt
      Relevante Links dazu:
      hurl-Dokumentation zu Captures
      Vscode-restclient
      httpyac-Dokumentation zu ref

    • Entschuldigung, dass wir noch ein weiteres Dateiformat geschaffen haben!
      Eine Möglichkeit, dieses Problem etwas zu verringern, ist hurlfmt
      Damit lassen sich Hurl-Dateien als JSON exportieren
      Auf Basis dieses JSON-Ergebnisses könnte man auch Konverter zu anderen Tools bauen
      Es ist keine magische, perfekte Lösung, aber beim Wechsel von Hurl in andere Formate kann es zumindest etwas helfen

    • Sowohl Visual Studio Code als auch Visual Studio unterstützen .HTTP-Dateien, sind aber nicht miteinander kompatibel
      Ein interessantes Beispiel dafür, wie Conway's Law in der Praxis sichtbar wird

  • Wirkt etwas ähnlich
    https://marketplace.visualstudio.com/items?itemName=humao.rest-client
    Diese VS-Code-Erweiterung ist für HTTP-bezogene Tests sehr leistungsfähig

    • Der wirklich große Unterschied ist, dass es editorunabhängig verwendet werden kann

    • IntelliJ hat ebenfalls eine ähnliche Funktion
      https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html

    • Ich habe Hurl auch benutzt und fand es ziemlich gut
      In letzter Zeit bevorzuge ich aber eher den .http-Ansatz
      In IntelliJ ist er eingebaut, es gibt das oben verlinkte Plugin, und für die CLI habe ich auch httpYac verwendet
      Es gibt keinen Vendor Lock-in, und über Source Control oder Copy-and-paste lässt es sich sehr einfach teilen

  • Auf der JVM nutze ich Karate für Integrationstests
    https://github.com/karatelabs/karate
    Weil man beliebig JavaScript einbetten kann, lassen sich Anfragen und Prüfungen flexibel formulieren