Hurl - un outil textuel en ligne de commande pour les requêtes et tests HTTP

(github.com/Orange-OpenSource)

27 points par GN⁺ 2025-06-21 | 3 commentaires | Partager sur WhatsApp

Un outil open source en ligne de commande qui permet d’exécuter des requêtes HTTP à partir d’un format de fichier texte simple, d’enchaîner plusieurs requêtes, d’extraire des valeurs, ainsi que d’interroger et de valider le corps et les en-têtes des réponses
Compatible avec de nombreuses API et requêtes basées sur REST, SOAP, GraphQL, HTML/XML/JSON, il convient aussi bien à la récupération de données qu’aux tests de session HTTP
Il permet l’enchaînement de requêtes, la capture de valeurs et diverses validations sur les codes d’état, en-têtes, corps, etc., et se prête bien à l’intégration CI/CD et à l’automatisation via des rapports JUnit, TAP, HTML, JSON, etc.
Distribué sous la forme d’un exécutable unique implémenté en Rust, il est facile à installer et s’appuie en interne sur le moteur libcurl pour offrir de hautes performances et une forte compatibilité protocolaire
Il est considéré comme un outil moderne d’automatisation des tests HTTP, avec une syntaxe concise, extensible et riche en fonctionnalités par rapport aux outils concurrents
En tant qu’open source piloté par la communauté, il se distingue par un format textuel intuitif et extensible très utile autant pour les développeurs que pour les équipes DevOps

What's Hurl?

Hurl est un outil qui permet d’écrire des requêtes HTTP dans un format texte clair et intuitif pour les exécuter en ligne de commande
Il permet d’enchaîner plusieurs requêtes, d’extraire des valeurs depuis les réponses et d’utiliser différentes requêtes d’inspection (en-têtes, corps, code d’état, etc.) afin de tester des scénarios HTTP complexes
Basé sur le moteur libcurl, il est fiable et prend en charge des protocoles récents comme IPv6 et HTTP/3
Il prend en charge la récupération de données, les tests de scénarios et les mesures de performance (temps de réponse, etc.)
Il est optimisé pour la génération de rapports (JUnit, TAP, HTML, etc.) et l’intégration aux pipelines CI/CD
Il fonctionne avec de nombreuses API comme REST, SOAP, GraphQL, HTML, XML, JSON, et prend aussi en charge l’analyse du corps (par ex. XPath, JSONPath)
Voici les principaux atouts propres à Hurl par rapport à d’autres outils de test HTTP (par ex. Postman, curl, etc.) :
- Son format en texte brut facilite le versioning et le travail collaboratif
- Il fournit un binaire léger unique écrit en Rust, sans runtime supplémentaire
- Il repose sur le même moteur réseau que curl (libcurl), ce qui garantit fiabilité et prise en charge de nombreux protocoles
- Il prend en charge divers formats comme REST, SOAP, GraphQL, HTML et permet de configurer des scénarios complexes
- Il s’intègre facilement à la CI/CD, à l’automatisation des tests et aux rapports détaillés (JUnit, HTML, TAP, etc.)

Résumé des principales fonctionnalités

Fonctionnement de base
- Exécute plusieurs requêtes HTTP écrites séquentiellement dans un fichier Hurl (.hurl)
- Permet d’extraire des valeurs depuis la réponse de chaque requête, de valider des conditions et de transmettre des données à la requête suivante
- Prend en charge divers formats comme REST/JSON, SOAP/XML, GraphQL, HTML, etc.
Enchaînement et utilisation de variables
- Permet d’écrire plusieurs requêtes en chaîne dans un même fichier
- La syntaxe Captures permet d’extraire des valeurs d’une réponse pour les injecter ensuite comme variables dans d’autres requêtes
- Extraction et réutilisation des données via XPath, JSONPath, expressions régulières, structure du corps, etc.
Différentes méthodes de requête et de validation
- Prend en charge la configuration de nombreux paramètres de requête, comme les query parameters, en-têtes ou mécanismes d’authentification
- La syntaxe [Asserts] ou la syntaxe implicite permet de valider le code d’état, le corps, les en-têtes, les cookies, le temps de réponse, les hash, etc.
- Utilise XPath et JSONPath, et permet aussi de tester des contenus REST/GraphQL/SOAP et HTML
- Prend en charge la validation de valeurs multiples, des propriétés du corps de réponse, des hash, des certificats, les délais de requête/réponse et les données binaires
Rapports de test et intégration à l’automatisation
- Produit des rapports d’exécution dans différents formats : texte, HTML, JUnit, TAP, JSON, etc.
- S’intègre facilement à des pipelines CI/CD
Contrôle avancé et fonctions utiles
- Transmission de données entre requêtes (capture et variables)
- Fonctions de génération de données dynamiques (newUuid, newDate, etc.)
- Personnalisation des options par requête
- Polling/réessais, délai entre requêtes, saut, masquage des valeurs sensibles (redact)
- Prise en charge des mêmes options que curl (réutilisation directe des options curl)
- Fonctions cloud intégrées comme l’authentification AWS Sigv4

Exemples d’utilisation

Définir de simples requêtes GET/POST ainsi que des enchaînements de requêtes multi-étapes dans un fichier texte simple
- Créer un fichier sample.hurl, puis exécuter la commande $ hurl sample.hurl pour lancer l’ensemble des requêtes en une seule fois

Exemple :

  GET https://example.org  
  HTTP 200  
  [Captures]  
  csrf_token: xpath &quot;string(//meta[@name='_csrf_token']/@content)&quot;  

  POST https://example.org/login?user=toto&amp;password=1234  
  X-CSRF-TOKEN: {{csrf_token}}  
  HTTP 302

Il est possible de tester plusieurs endpoints d’API et de comparer les valeurs de réponse, de réutiliser des valeurs enchaînées (jetons, etc.) et de valider le code d’état, les en-têtes et les données du corps

Cas d’usage représentatifs

Tests d’API variées : REST/GraphQL/HTML/JSON/SOAP
Extraction et réutilisation de valeurs comme les jetons CSRF, l’authentification et l’autorisation
Validation fine des codes d’état, en-têtes, données du corps, cookies, certificats SSL, etc.
Automatisation et supervision de scénarios métier réels (connexion jusqu’aux actions métier, etc.)
Prise en charge multiplateforme et de nombreuses méthodes d’installation (Linux, macOS, Windows, Docker, npm, Cargo, etc.)

Principales options CLI

--test : mode test (affichage du résumé et des rapports)
--report-html, --report-json, --report-junit, --report-tap : prise en charge de différents formats de rapport
--parallel, --jobs N : exécution en parallèle
--retry, --retry-interval : nouvelle tentative automatique / attente
-u, --user : saisie des informations d’authentification
--variable, --variables-file : définition de variables
-o, --output : enregistrement du fichier de réponse
--json : sortie des résultats d’exécution au format JSON

Méthodes d’installation

Installation possible de plusieurs façons : Homebrew, apt, yum, pacman, cargo, choco, scoop, Docker, npm, etc.
Aucun runtime supplémentaire n’est nécessaire grâce au binaire unique

Exemple :

brew install hurl

cargo install --locked hurl

Avantages par rapport aux outils concurrents

Plus adapté qu’un outil GUI comme Postman ou Insomnia à une approche textuelle, au versioning et à l’intégration CI/CD
Plus spécialisé que curl pour les tests, l’exécution de scénarios, les validations et l’automatisation des rapports
Courbe d’apprentissage plus faible grâce à un format maison intuitif, plutôt qu’un DSL complexe en YAML, JSON, etc.

3 commentaires

seunggi 2025-07-04

Bruno - un client API open source rapide et compatible avec Git (une alternative à Postman)
https://fr.news.hada.io/topic?id=13730

xguru 2025-06-21

Sortie de Hurl 4.0.0
Il était déjà en 4.0 il y a deux ans, et la version actuelle est maintenant la 6.1.1.

GN⁺ 2025-06-21

Commentaires Hacker News

J’ai commencé à utiliser hurl ces derniers mois
J’apprécie énormément le fait qu’on puisse l’utiliser à la fois en mode suite de tests et en mode appel individuel
Je m’en sers pour exécuter des suites de tests de requêtes HTTP dans la CI
Je trouve que le langage de configuration par blocs n’est pas très intuitif, et que la documentation sur les assertions prises en charge est un peu insuffisante
Globalement, l’outil apporte une grande valeur
J’ai commencé à tester des interfaces pendant un travail de POC, et j’ai découvert que cette approche pouvait aider au développement basé sur les LLM
En écrivant les tests directement sur les méthodes HTTP, les tests et l’implémentation restent séparés de manière plus souple au fil de l’évolution du projet
Cette séparation rend aussi la frontière entre interface et implémentation plus claire
Avant d’adopter hurl, j’écrivais les tests avec le framework de test du langage du service, mais les tests basés sur hurl m’obligent à conserver strictement le « point de vue client »
Sans accès détourné aux données en backdoor, l’interface, les tests et l’implémentation sont rigoureusement séparés, ce qui est rassurant
- Je suis le développeur de hurl
  Merci pour le retour
  Quand j’ai commencé le développement il y a 6 ou 7 ans, j’ai d’abord essayé le JSON, puis le format YAML, mais j’ai progressivement été convaincu qu’il fallait créer un nouveau format de fichier
  Je comprends tout à fait que cela puisse sembler étrange du point de vue des utilisateurs
  J’ai essayé d’appliquer une syntaxe simple aux cas simples, mais ce n’est peut-être pas parfait
  Pour la documentation, s’il y a des manques ou des pistes d’amélioration, je serais ravi de recueillir des retours et de l’améliorer
Hurl est vraiment un super outil
Quand j’ai porté un service web auparavant écrit en Python vers Rust, les tests stricts de l’API publique m’ont beaucoup aidé
Grâce à un environnement de tests d’intégration indépendant du langage, on peut garder l’API ou le site web tel quel et ne remplacer que le backend
Il y a aussi un avantage particulier quand on utilise Hurl avec Rust
On peut l’intégrer à cargo test et utiliser directement la bibliothèque hurl, tout en réutilisant les fichiers .hurl tels quels
Démo : https://github.com/perrygeo/axum-hurl-test
J’ai commencé à utiliser Hurl en septembre 2023
Je faisais tourner mes suites de tests avec Runscope, mais le fait que les changements ne soient pas versionnés était vraiment pénible
Après un peu de travail préparatoire, je suis passé à Hurl et j’ai abandonné Runscope
Maintenant je peux voir d’un coup d’œil qui a changé quoi, quand et pourquoi, et j’en suis très satisfait
- Je détestais vraiment le fait que les changements ne soient pas versionnés dans Runscope
  Notre équipe a aussi essayé de résoudre ce problème, au point de perdre de l’élan sur le projet
Le concept me paraît bon, mais je me demande quand même « pourquoi l’utiliser »
Je développe avec Django, et les fonctions de test intégrées au framework sont déjà très complètes
Introduire un outil externe qui ne connaît pas mon propre backend me semble surtout ajouter une charge de synchronisation
Et cela empêche aussi de sauter directement dans le débogueur quand quelque chose cloche
Il y a certes l’argument selon lequel il faut séparer clairement le code de test du code backend, mais en pratique cela augmente surtout le coût de maintenance
Au final, il faudra quand même exécuter la suite de tests native, donc utiliser plusieurs outils externes en parallèle me semble maladroit
Cela dit, pour vérifier à quel point une API se comporte de manière générique, ça peut peut-être valoir le coup
- Je me suis souvent posé la même question : pourquoi utiliser un outil qui ne connaît pas mon backend et m’ajoute juste du travail de synchronisation ?
  Je n’ai jamais utilisé hurl, mais j’ai souvent utilisé des outils indépendants du langage pour tester des API, et j’en développe même un moi-même
  Voici pourquoi ces outils me paraissent intéressants
  - Le fait qu’ils ne connaissent pas l’implémentation interne est justement un avantage
    Comme ils valident uniquement les entrées et les sorties, ils ne dépendent pas de la logique interne
  - Comme ils sont indépendants du langage, on peut les partager avec d’autres équipes et même les utiliser comme documentation (ou à la place d’une spécification OpenAPI)
  - Puisqu’ils testent le contrat de l’API lui-même, ils restent réutilisables même lors de grandes migrations
    Par exemple, en migrant une API publique de Perl vers Go, on peut utiliser l’ancienne API Perl comme test de non-régression, puis exécuter exactement les mêmes tests sur l’API Go, ce qui inspire davantage confiance
  - Quand les développeurs écrivent ce type de tests, cela leur permet temporairement d’adopter le point de vue du consommateur de l’API, ce qui aide à produire des tests de meilleure qualité
- Il faut le voir comme une alternative à un produit comme Postman
  Pas besoin d’ouvrir une lourde fenêtre basée sur Electron juste pour tester rapidement quelques requêtes HTTP
  C’est quelque part entre des scripts curl et Postman, donc c’est idéal pour ceux qui veulent à la fois légèreté et confort
- Nous avons utilisé Hurl lors d’une migration d’un serveur web ktor vers du code basé sur spring boot (stack Java/Kotlin)
  Le fait de pouvoir faire tourner une suite de tests au niveau de la spécification, indépendamment de la stack serveur, a rendu la transition très fluide
  Nous utilisons aussi des images Docker en production, et Hurl nous a permis de faire des tests d’intégration très légers et indépendants, au lieu d’utiliser des outils trop dépendants de l’implémentation
La section d’exemples (https://github.com/Orange-OpenSource/hurl?tab=readme-ov-file#samples) est très convaincante pour les personnes qui veulent comprendre l’intérêt de l’outil en 5 minutes, c’est-à-dire celles qui ont tendance à juger à l’avance
Il m’arrive souvent d’être comme ça, et c’est vraiment impressionnant
Je suis le mainteneur de Hurl
Les questions et retours sont toujours les bienvenus
- C’est un schéma que moi et beaucoup de développeurs autour de moi utilisons souvent : écrire les tests dans des fichiers ".http" exécutables via une extension IDE de VS Code ou d’IDEA
  Le format d’exemple est
```
POST http://localhost:8080/api/foo
Content-Type: application/json
{ "some": "body" }
```
  Ensuite, on compare la sortie en 1:1 avec un fichier "expected.json" pour faire les tests d’intégration
  On exécute ces fichiers avec cURL et des scripts bash sur mesure, puis on compare les résultats avec jq pour consigner en console le succès ou l’échec
  Je me demande si avec Hurl on peut aussi définir ce genre de requêtes HTTP d’exemple et des résultats attendus basés sur des fichiers JSON directement depuis l’IDE
  Et je me demande aussi si Hurl peut exécuter automatiquement plusieurs fichiers d’un dossier
- Hurl est sous-estimé pour sa capacité à écrire joliment des suites de tests au niveau HTTP et à les maintenir facilement
  Merci d’avoir développé un tel outil
- Je suis très satisfait du choix du nom Hurl
  J’admire le sens du style du développeur
- J’ai utilisé Hurl pendant un moment, puis j’ai même commencé à y contribuer
  Je me demande quelles sont les chances de voir apparaître une fonctionnalité "include"
- Merci de continuer à maintenir le projet
  Je serais curieux de savoir comment tu vois la vision et l’avenir de Hurl dans 2 ans
Ce projet m’a beaucoup inspiré et j’ai conçu moi-même un outil de test HTTP
Nous avions besoin d’exécuter rapidement des centaines de tests en parallèle, et si Hurl vous plaît, un outil comme Nap pourrait aussi vous intéresser
- Je me demande si la syntaxe ou le contenu de la configuration sont les mêmes que pour Hurl, et quels sont les points de différence
  S’il existe une page qui résume les différences, j’aimerais bien la voir
Ça a l’air intéressant
J’ai longtemps utilisé Vscode-restclient, mais récemment je passe à httpyac pour les scripts et l’usage en CLI
Je compte aussi regarder si Hurl correspond à ce que je recherche
L’un des points gênants avec les outils de test, c’est qu’il n’existe pas encore de standard dans les fichiers .http pour référencer le résultat d’une requête comme entrée de la suivante
Les trois outils que j’ai utilisés jusqu’ici ont tous une méthode différente
- hurl utilise [Captures]
- Vscode-restclient référence le nom de la requête dans une déclaration de variable
- httpyac utilise la syntaxe @ref
  Comme chaque syntaxe est différente, ce qu’on écrit pour un outil casse ailleurs
  Liens de référence associés
  documentation de capture hurl
  Vscode-restclient
  documentation ref de httpyac
- Désolé d’avoir créé encore un autre format de fichier !
  Pour atténuer un peu ce problème, on peut utiliser hurlfmt
  hurlfmt permet d’exporter les fichiers Hurl au format JSON
  On peut ensuite se servir de ce résultat JSON pour créer des conversions vers ou depuis d’autres outils
  Ce n’est pas une solution magique et parfaite, mais cela peut aider un peu lors d’une migration de Hurl vers d’autres formats
- Visual Studio Code et Visual Studio prennent tous deux en charge les fichiers .HTTP, mais ils ne sont pas compatibles entre eux
  C’est intéressant comme exemple concret de la loi de Conway à l’œuvre
Cela semble un peu similaire
https://marketplace.visualstudio.com/items?itemName=humao.rest-client
Cette extension VS Code est très puissante pour les tests liés à HTTP
- Le grand point de différence, c’est qu’on peut l’utiliser indépendamment de l’éditeur
- IntelliJ a aussi une fonctionnalité similaire
  https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html
- J’ai aussi essayé Hurl et je l’ai trouvé plutôt correct
  Mais récemment, j’ai fini par préférer l’approche en .http
  C’est intégré à IntelliJ, il y a aussi le plugin lié plus haut, et côté CLI j’ai également utilisé httpYac
  Il n’y a pas de vendor lock-in, et c’est très facile à partager via le contrôle de source ou par copier-coller
Sur la JVM, j’utilise Karate pour les tests d’intégration
https://github.com/karatelabs/karate
Comme on peut y inclure librement du JavaScript, cela permet d’écrire les requêtes et les validations de façon flexible

Hurl - un outil textuel en ligne de commande pour les requêtes et tests HTTP

What's Hurl?

Résumé des principales fonctionnalités

Fonctionnement de base

Enchaînement et utilisation de variables

Différentes méthodes de requête et de validation

Rapports de test et intégration à l’automatisation

Contrôle avancé et fonctions utiles