Hurl - herramienta basada en texto para solicitudes HTTP y pruebas desde la línea de comandos

 (github.com/Orange-OpenSource)
27 puntos por GN⁺ 2025-06-21 | 3 comentarios | Compartir por WhatsApp
  • Herramienta de línea de comandos open source que permite ejecutar solicitudes HTTP con un formato simple de archivo de texto, encadenar múltiples solicitudes, extraer valores y hacer consultas/validaciones sobre el cuerpo y los encabezados de la respuesta
  • Compatible con diversas API y solicitudes basadas en REST, SOAP, GraphQL y HTML/XML/JSON, por lo que sirve tanto para consultar datos como para probar sesiones HTTP
  • Permite encadenar solicitudes, capturar valores y realizar distintas validaciones sobre códigos de estado, encabezados, cuerpo y más, y resulta útil para la integración con CI/CD y la automatización mediante reportes como Junit, TAP, HTML y JSON
  • Se distribuye como un ejecutable único implementado en Rust, lo que hace que su instalación sea sencilla; internamente usa el motor libcurl para ofrecer gran velocidad y una sólida compatibilidad de protocolos
  • Se le considera una herramienta moderna de automatización de pruebas HTTP, con una sintaxis concisa, extensibilidad y múltiples funciones frente a herramientas competidoras
  • Como open source impulsado por la comunidad, muestra una alta utilidad tanto para desarrolladores como para equipos DevOps gracias a su formato basado en texto, intuitivo y extensible

What's Hurl?

  • Hurl es una herramienta para escribir solicitudes HTTP en un formato de texto claro e intuitivo y ejecutarlas desde la línea de comandos
  • Permite encadenar varias solicitudes, extraer valores de las respuestas y usar diversas consultas (encabezados, cuerpo, código de estado, etc.) para probar escenarios HTTP complejos
  • Basada en el motor libcurl, ofrece alta confiabilidad y soporte para protocolos modernos como IPv6 y HTTP/3
  • Admite consulta de datos, pruebas de escenarios y medición de rendimiento (como tiempos de respuesta)
  • Está optimizada para la generación de reportes (Junit, TAP, HTML, etc.) y la integración con pipelines de CI/CD
  • Soporta diversas API como REST, SOAP, GraphQL, HTML, XML y JSON, además de análisis del cuerpo (por ejemplo, XPath y JSONPath)
  • Estas son algunas ventajas clave de Hurl frente a otras herramientas de pruebas HTTP (por ejemplo, Postman o curl):
    • Al estar escrito en texto plano, facilita el control de versiones y la colaboración
    • Ofrece un binario único y liviano escrito en Rust, sin necesidad de runtime adicional
    • Está basado en el mismo motor de red que curl (libcurl), lo que aporta confiabilidad y soporte para múltiples protocolos
    • Soporta varios formatos como REST, SOAP, GraphQL y HTML, y permite configurar escenarios complejos
    • Se integra fácilmente con CI/CD, automatización de pruebas y reportes detallados (JUnit, HTML, TAP, etc.)

Resumen de funciones principales

  • Funcionamiento básico

    • Ejecuta múltiples solicitudes HTTP escritas secuencialmente dentro de un archivo Hurl (.hurl)
    • Permite extraer valores de la respuesta de cada solicitud, validar condiciones y pasar datos a la siguiente solicitud
    • Compatible con varios formatos como REST/JSON, SOAP/XML, GraphQL y HTML

  • Encadenamiento y uso de variables

    • Permite escribir múltiples solicitudes encadenadas dentro de un solo archivo
    • Con la sintaxis de Captures, extrae valores de la respuesta y los inyecta como variables en solicitudes posteriores
    • Permite extraer y usar datos mediante XPath, JSONPath, expresiones regulares y la estructura del cuerpo

  • Distintas formas de solicitud y validación

    • Soporta la configuración de varias especificaciones de solicitud como parámetros de consulta, encabezados y autenticación
    • Con la sintaxis [Asserts] o con sintaxis implícita, permite validar código de estado, cuerpo, encabezados, cookies, tiempo de respuesta, hash y más
    • Usa XPath y JSONPath, y también puede probar contenido REST/GraphQL/SOAP y HTML
    • Soporta validación de múltiples valores, cuerpo de respuesta/hash/propiedades del certificado, latencia de solicitud/respuesta y manejo de datos binarios

  • Reportes de pruebas e integración con automatización

    • Muestra los resultados de ejecución en varios formatos de reporte como texto, HTML, JUnit, TAP y JSON
    • Puede integrarse fácilmente en pipelines de CI/CD

  • Control avanzado y funciones útiles

    • Transferencia de datos entre solicitudes (captura y parametrización)
    • Funciones para generar datos dinámicos (newUuid, newDate, etc.)
    • Personalización de opciones por solicitud
    • Polling/reintentos, retraso de solicitudes, omisión y enmascaramiento de valores secretos (redact)
    • Soporte para las mismas opciones que curl (se pueden usar directamente opciones de curl)
    • Funciones integradas específicas de nube, como autenticación AWS Sigv4

Ejemplos de uso

  • Define solicitudes GET/POST simples y encadenamiento de solicitudes de múltiples pasos en archivos de texto sencillos
    • Crea el archivo sample.hurl y ejecuta el comando $ hurl sample.hurl para procesar todas las solicitudes en lote
  • Ejemplo: 
      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
  • Permite probar múltiples endpoints de API y comparar valores de respuesta, usar valores encadenados (como tokens) y validar código de estado, encabezados y datos del cuerpo

Casos de uso representativos

  • Pruebas de diversas API como REST/GraphQL/HTML/JSON/SOAP
  • Extracción y reutilización de valores como tokens CSRF, autenticación y autorización
  • Validaciones precisas de código de estado, encabezados, datos del cuerpo, cookies y certificados SSL
  • Automatización y monitoreo de escenarios reales de servicio (inicio de sesión ~ flujos de trabajo, etc.)
  • Soporte multiplataforma y varios métodos de instalación (Linux, macOS, Windows, Docker, npm, Cargo, etc.)

Principales opciones de CLI

  • --test: modo de prueba (muestra resumen y reportes)
  • --report-html, --report-json, --report-junit, --report-tap: soporte para varios formatos de reporte
  • --parallel, --jobs N: ejecución en paralelo
  • --retry, --retry-interval: reintento/espera automáticos
  • -u, --user: ingreso de credenciales de autenticación
  • --variable, --variables-file: definición de variables
  • -o, --output: guardar archivo de respuesta
  • --json: salida de resultados de ejecución en formato JSON

Método de instalación

  • Se puede instalar de varias formas, incluyendo Homebrew, apt, yum, pacman, cargo, choco, scoop, Docker y npm
  • Al ser un binario único, no requiere runtime adicional
  • Ejemplo: 
    brew install hurl
    o 
    cargo install --locked hurl

Ventajas frente a herramientas competidoras

  • Frente a herramientas GUI como Postman o Insomnia, ofrece más ventajas para formato basado en texto, control de versiones e integración con CI/CD
  • Frente a curl, está más especializada en pruebas, ejecución de escenarios, validación y automatización de reportes
  • Tiene una curva de aprendizaje menor gracias a su formato propio intuitivo, en lugar de DSL complejos como YAML o JSON

Lecturas relacionadas

3 comentarios

 
seunggi 2025-07-04

Bruno - cliente API de código abierto, rápido y amigable con Git (alternativa a Postman)
https://es.news.hada.io/topic?id=13730
 
xguru 2025-06-21

Lanzamiento de Hurl 4.0.0
Hace 2 años era la versión 4.0, pero actualmente ya salió hasta la 6.1.1.
 
GN⁺ 2025-06-21
Comentarios de Hacker News

  • Empecé a usar hurl hace unos meses
    Me gusta mucho que se pueda usar tanto en modo suite de pruebas como en modo de invocaciones individuales
    Lo uso para ejecutar suites de pruebas de solicitudes HTTP en CI
    Siento que el lenguaje de configuración por bloques no es tan intuitivo, y que la documentación sobre las assertions compatibles es algo escasa
    En general, la herramienta aporta muchísimo valor
    Empecé a probar interfaces al trabajar en POCs, y descubrí que este enfoque puede ayudar al desarrollo basado en LLM
    Al escribir las pruebas directamente sobre los métodos HTTP, las pruebas y la implementación quedan separadas con más flexibilidad a medida que evoluciona el proyecto
    Gracias a esa separación, el límite entre la interfaz y la implementación queda más claro
    Antes de adoptar hurl, escribía las pruebas con el framework de testing del lenguaje del servicio, pero con pruebas basadas en hurl terminé respetando estrictamente la “perspectiva del cliente”
    Sin accesos traseros a los datos ni cosas por el estilo, la interfaz, las pruebas y la implementación quedan completamente separadas, y eso da tranquilidad

    • Soy el desarrollador de hurl
      Gracias por los comentarios
      Cuando empecé el desarrollo hace 6 o 7 años, primero probé con JSON y después con formato YAML, pero poco a poco me convencí de crear directamente un formato de archivo nuevo
      Entiendo perfectamente que eso pueda sentirse extraño desde la perspectiva del usuario
      Intenté aplicar una sintaxis simple para los casos más simples, pero puede que no sea perfecta
      En cuanto a la documentación, si hay carencias o puntos a mejorar, espero recibir opiniones activamente y seguir mejorándola

  • Hurl es una herramienta realmente genial
    Cuando antes porté un servicio web escrito en Python a Rust, tener pruebas estrictas de la API pública fue de gran ayuda
    Gracias a un entorno de pruebas de integración independiente del lenguaje, pude dejar igual la API o el sitio web y cambiar solo el backend
    Hay una ventaja especial adicional al usar Hurl con Rust
    Se puede integrar con cargo test y usar directamente la librería hurl, además de reutilizar tal cual los archivos .hurl
    Demo: https://github.com/perrygeo/axum-hurl-test

  • Empecé a usar Hurl en septiembre de 2023
    Antes ejecutaba suites de pruebas con Runscope, pero me resultaba muy molesto que los cambios no quedaran bajo control de versiones
    Hice el trabajo base para migrar a Hurl y abandoné Runscope
    Ahora estoy satisfecho porque puedo ver de un vistazo quién cambió qué, cuándo y por qué

    • Realmente odiaba que los cambios en Runscope no quedaran bajo control de versiones
      Nuestro equipo también intentó resolver ese problema y el proyecto perdió impulso por eso

  • Creo que el concepto en sí es bueno, pero me hace preguntarme “por qué debería usarlo”
    Yo desarrollo con Django, y las funciones de testing integradas del framework ya son muy completas
    Introducir una herramienta externa que no conoce mi propio backend me parece que solo aumentaría la carga de sincronización
    Además, si algo sale raro, tampoco podría saltar de inmediato al depurador
    Existe la lógica de que el código de pruebas y el código del backend deberían estar claramente separados, pero en la práctica el costo de mantenimiento aumenta más
    Al final igual tendría que ejecutar la suite de pruebas nativa, así que usar varias herramientas externas en paralelo me resulta incómodo
    Dicho eso, quizá sí valga la pena si el objetivo es validar qué tan genéricamente funciona la API

    • Yo también me pregunté mucho eso de por qué usar una herramienta que no conoce mi backend y solo me agregaría trabajo de sincronización
      Nunca he usado hurl, pero sí he usado varias veces herramientas para probar APIs de manera independiente del lenguaje, e incluso estoy desarrollando una yo mismo
      Estas herramientas me parecen buenas por varias razones

      • Que no necesiten conocer la implementación interna es más bien una ventaja
        Como validan solo input y output, no dependen de la lógica interna
      • Al ser independientes del lenguaje, se pueden compartir con otros equipos y hasta usarse como documentación (o en lugar de una especificación OpenAPI)
      • Como prueban el contrato mismo de la API, también se pueden reutilizar en migraciones grandes
        Por ejemplo, al mover una API pública de Perl a Go, se puede usar la API existente en Perl como prueba de no regresión y reutilizar exactamente las mismas pruebas en la API en Go, lo que da mucha confianza
      • Cuando los desarrolladores escriben este tipo de pruebas, pueden cambiar por un momento a la perspectiva del consumidor de la API, y eso les ayuda a crear pruebas de mayor calidad

    • Se puede ver como un reemplazo de productos tipo Postman
      No hace falta abrir una ventana pesada basada en Electron solo para probar unas cuantas solicitudes HTTP simples
      Está en algún punto entre scripts de curl y Postman, así que es ideal para quien necesita ligereza y comodidad al mismo tiempo

    • Nosotros usamos Hurl al migrar de un servidor web ktor a código basado en spring boot (stack Java/Kotlin)
      Como podíamos operar una suite de pruebas a nivel de especificación sin depender del stack del servidor, la transición fue muy fluida
      Además, como usamos imágenes de Docker en producción, con Hurl pudimos hacer pruebas de integración muy ligeras e independientes, en lugar de usar herramientas demasiado acopladas a la implementación

  • La sección de ejemplos (https://github.com/Orange-OpenSource/hurl?tab=readme-ov-file#samples) resulta muy convincente para quienes quieren captar las ventajas de la herramienta en 5 minutos, es decir, para la gente que tiende a juzgar por adelantado
    A veces yo también soy de ese tipo, y la verdad impresiona mucho

  • Soy el mantenedor de Hurl
    Las preguntas o comentarios siempre son bienvenidos

    • Es un patrón que yo y varios desarrolladores a mi alrededor usamos bastante: escribimos pruebas en archivos ".http" que se pueden ejecutar con extensiones de IDE como VS Code o IDEA
      Un formato de ejemplo sería

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

      Luego comparamos el output uno a uno con un archivo "expected.json" para hacer pruebas de integración
      Ejecutamos estos archivos con cURL y scripts bash hechos a medida, y comparamos los resultados con jq para dejar en consola el log de éxito o fallo
      Tengo curiosidad por saber si con Hurl también se puede definir en el IDE este tipo de solicitudes HTTP de ejemplo y resultados esperados basados en archivos JSON
      Y también si Hurl puede ejecutar automáticamente varios archivos dentro de una carpeta

    • Hurl está subestimado en lo bien que permite escribir suites de pruebas a nivel HTTP de forma elegante y fácil de mantener
      Gracias por desarrollar una herramienta así

    • Estoy muy satisfecho con el nombre Hurl
      Me impresiona mucho el sentido que tuvo el desarrollador para nombrarlo

    • Usé Hurl durante un tiempo e incluso contribuí directamente
      Me pregunto qué posibilidad hay de ofrecer una función de "include"

    • Solo quería agradecer que se siga manteniendo
      Me gustaría saber cuál es la visión y el futuro de Hurl dentro de 2 años

  • Me inspiré mucho en este proyecto y diseñé mi propia herramienta de pruebas HTTP
    Necesitábamos ejecutar en paralelo cientos de pruebas rápidamente, y si te gusta Hurl, quizá también te interese una herramienta llamada Nap

    • Me da curiosidad si la sintaxis o el contenido de configuración son iguales a los de Hurl, y en qué se diferencian
      Si existe una página que resuma las diferencias, me gustaría conocerla

  • Se ve interesante
    Originalmente usé Vscode-restclient durante mucho tiempo, pero últimamente me estoy moviendo a httpyac para scripting y uso por CLI
    También pienso revisar si Hurl encaja con lo que necesito
    Una de las molestias al usar herramientas de pruebas es que todavía no existe un estándar en archivos .http para referenciar el resultado de una solicitud como entrada de la siguiente
    Las tres herramientas que he usado hasta ahora lo hacen de forma distinta

    • hurl usa [Captures]

    • Vscode-restclient referencia el nombre de la solicitud en la declaración de variables

    • httpyac usa la sintaxis @ref
      Como cada una tiene una sintaxis diferente, lo que escribes para una herramienta se rompe en otra
      Enlaces de referencia relacionados
      documentación de captures de hurl
      Vscode-restclient
      documentación de ref de httpyac

    • ¡Perdón por crear otro formato de archivo más!
      Una forma de reducir un poco este problema es usar hurlfmt
      hurlfmt permite exportar archivos Hurl a JSON
      Con ese resultado JSON, también se pueden crear conversiones hacia otras herramientas
      No es una solución mágica perfecta, pero puede ayudar un poco al pasar de Hurl a otros formatos

    • Tanto Visual Studio Code como Visual Studio soportan archivos .HTTP, pero no son compatibles entre sí
      Me parece interesante como un caso real de Conway's Law

  • Se ve algo similar
    https://marketplace.visualstudio.com/items?itemName=humao.rest-client
    Esta extensión de VS Code es muy potente para testing relacionado con HTTP

    • La gran diferencia es que se puede usar de forma independiente del editor

    • IntelliJ también tiene una función similar
      https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html

    • Yo también probé Hurl y me pareció bastante bueno
      Pero últimamente prefiero más el enfoque de .http
      Está integrado en IntelliJ, está el plugin enlazado arriba, y en CLI también he usado httpYac
      No hay vendor lock-in y además es muy fácil compartirlo por source control o copiando y pegando

  • En la JVM hago pruebas de integración con Karate
    https://github.com/karatelabs/karate
    Como permite incluir JavaScript arbitrario, se pueden escribir solicitudes y validaciones con mucha flexibilidad