C'EST QUOI ?
Hurl est un binaire Rust qui lit des fichiers .hurl - un format texte minimaliste pour décrire des requêtes HTTP - et les exécute séquentiellement. Chaque requête peut inclure des assertions sur la réponse (status code, headers, body via JSONPath ou XPath) et capturer des valeurs pour les injecter dans les requêtes suivantes. Sous le capot, c'est libcurl qui fait le travail réseau, ce qui garantit un support solide de HTTP/1.1, HTTP/2, HTTP/3 et IPv6.
Le format .hurl est volontairement simple : une requête = une méthode, une URL, des sections optionnelles. Pas de langage de programmation, pas de DSL complexe. Le fichier se lit comme une conversation HTTP.
GET https://api.example.com/health
HTTP 200
[Asserts]
jsonpath "$.status" == "ok"
POST https://api.example.com/login
{
"user": "admin",
"password": "secret"
}
HTTP 200
[Captures]
token: jsonpath "$.token"
GET https://api.example.com/protected
Authorization: Bearer {{token}}
HTTP 200
POURQUOI C'EST INTERESSANT ?
C'est du texte, point. Les fichiers .hurl se versionnent dans Git, se diff facilement, se relisent en code review sans effort. Pas de format binaire ou de JSON illisible a la Postman.
Les assertions sont natives. Pas besoin de scripter un parseur JSON maison. JSONPath, XPath, regex, vérification de headers, de cookies, de certificats SSL, durée de réponse - tout est intégré dans la syntaxe. Une assertion qui échoue = un code de retour non-zero. Simple.
Le chainage est naturel. Capturer un token d'authentification, un ID de ressource, un cookie de session, puis le réinjecter dans les requêtes suivantes avec {{variable}}. C'est le workflow standard pour tester un flux complet.
CI/CD sans friction. Hurl génère des rapports en JUnit XML, TAP, JSON et HTML. Il s'intègre dans n'importe quel pipeline sans adaptateur. Un binaire statique, zero dépendance runtime, disponible via apt, brew, cargo, npm, conda ou Docker.
Retry et polling. Pour les tests d'intégration qui dépendent d'un service asynchrone, Hurl supporte le retry avec intervalle configurable et des conditions d'arrêt basées sur les assertions.
CAS D'USAGE
- Tests d'intégration d'API REST, SOAP ou GraphQL dans le pipeline CI
- Smoke tests post-déploiement avec assertions sur les endpoints critiques
- Remplacement de collections Postman par des fichiers versionnables et reviewables
- Validation de flows multi-étapes : authentification, CRUD, vérification
- Monitoring léger d'endpoints avec vérification de temps de réponse