El cliente HTTP, HTTPPie, moderno para probar APIs REST en Linux

Probar una API con curl a menudo significa escribir comandos largos llenos de flags -H y -d, y luego lidiar con un muro de JSON sin formatear. HTTPie hace que probar APIs sea más fácil con sintaxis de petición legible, manejo automático de JSON y salida coloreada y formateada, permitiéndote enviar peticiones con datos, cabeceras y autenticación directamente desde el terminal.

Si administras servidores web o trabajas con APIs, probablemente envías peticiones HTTP desde el terminal varias veces al día. Puede que compruebes si un endpoint de health devuelve HTTP 200 después de un despliegue, publiques datos de prueba en una API nueva, o verifiques qué cabeceras añade un proxy inverso.

curl maneja todas estas tareas, pero enviar JSON a menudo requiere flags extra, comillas cuidadosas y una herramienta separada como jq para hacer la respuesta más legible.

HTTPie (pronunciado aitch-tii-tii-pai) es un cliente HTTP de línea de comandos de código abierto escrito en Python, diseñado para hacer el trabajo con APIs y servidores HTTP más cómodo. Especificas el método HTTP, la URL y los datos de la petición usando una sintaxis legible, y HTTPie se encarga del formateo de la petición y muestra las respuestas soportadas con colores e indentación.

Proporciona dos comandos, http y https, para enviar peticiones HTTP y HTTPS respectivamente. El comando https asume el esquema https:// cuando no se especifica uno.

💡 Esta guía actualizada reemplaza al artículo antiguo de HTTPie, que cubría HTTPie 1.x. Desde entonces, el proyecto se ha movido al repositorio httpie/cli en GitHub, ha eliminado el soporte de Python 2.7, ha introducido la sintaxis JSON anidada y ha añadido el comando httpie cli para gestionar plugins.

La última versión listada en la documentación oficial es HTTPie 3.2.4, publicada el 1 de noviembre de 2024. Verifica el estado del release de nuevo justo antes de publicar.

Cómo HTTPie construye una petición a partir de los ítems de petición

Antes de instalar nada, conviene entender cómo HTTPie parsea una línea de comandos. Casi todos los ejemplos posteriores usan el mismo puñado de separadores. Una vez que los entiendas, podrás construir la mayoría de peticiones HTTP sin consultar la sintaxis.

La sintaxis general es así:

http [FLAGS] [MÉTODO] URL [ÍTEM ...]

El método HTTP es opcional. Si lo omites, HTTPie usa GET cuando no se suministran datos de petición y POST cuando sí se suministran. También puedes usar un atajo para localhost: http :8080/health envía una petición a http://localhost:8080/health, lo cual es útil al probar un servicio que corre en tu propia máquina.

Todo lo que va después de la URL es un ítem de petición. HTTPie determina el tipo de cada ítem por el separador entre su clave y su valor:

💡 La diferencia entre = y := atrapa a muchos principiantes. Considera estos dos ejemplos:

http POST https://api.example.com/devices port=8080
http POST https://api.example.com/devices port:=8080

• El primero envía "port": "8080" como string JSON.
• El segundo envía "port": 8080 como número JSON.

Si un esquema de API requiere un entero, enviar un string puede hacer que la validación falle. La respuesta exacta depende de cómo maneje la API la entrada inválida.

Memoriza estos separadores y podrás construir cabeceras, parámetros de query, cuerpos JSON y subidas de archivos directamente desde la línea de comandos con mucho menos tecleo.

Resumen visual de separadores

Cabecera:valor         → header HTTP
clave==valor           → query string (?clave=valor)
clave=valor            → JSON string   "clave": "valor"
clave:=valor           → JSON crudo    "clave": valor (número, bool, etc.)
campo@ruta             → subida multipart (requiere --form)
campo=@ruta            → contenido de archivo como string
campo:=@ruta.json      → contenido de archivo como JSON

Instalación de HTTPie

Ahora que la sintaxis tiene sentido, instalemos HTTPie. La mayoría de distribuciones Linux importantes lo empaquetan, aunque la versión disponible depende de la distribución y de su ciclo de releases.

Ubuntu y Debian (repositorios)

sudo apt update
sudo apt install -y httpie

💡 En Ubuntu, el paquete está disponible a través del componente universe, que puede que necesites habilitar primero.

Ubuntu y Debian (repositorio oficial del proyecto)

Si quieres usar la versión proporcionada por el proyecto HTTPie, añade su repositorio APT oficial y su clave de firma:

curl -SsL https://packages.httpie.io/deb/KEY.gpg | sudo gpg --dearmor -o /usr/share/keyrings/httpie.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/httpie.gpg] https://packages.httpie.io/deb ./" \
  | sudo tee /etc/apt/sources.list.d/httpie.list > /dev/null
sudo apt update
sudo apt install -y httpie

⚠️ Esta configuración del repositorio especifica amd64. Si usas ARM64 u otra arquitectura, comprueba las arquitecturas soportadas por el repositorio antes de usar esta entrada.

Fedora (repositorios estándar)

sudo dnf install -y httpie

Rocky Linux, AlmaLinux y RHEL (EPEL + CRB)

En distribuciones Enterprise Linux como Rocky Linux, AlmaLinux y RHEL, HTTPie está disponible a través de EPEL para algunas versiones. También puede que necesites el repositorio CRB, que proporciona dependencias requeridas por ciertos paquetes de EPEL.

Para Rocky Linux 9 y 10:

sudo dnf install -y epel-release
sudo dnf config-manager --set-enabled crb
sudo dnf install -y httpie

Para Rocky Linux 8, habilita PowerTools en lugar de CRB:

sudo dnf install -y epel-release
sudo dnf config-manager --set-enabled powertools
sudo dnf install -y httpie

⚠️ La disponibilidad del paquete varía según el release. El índice de paquetes de Fedora lista HTTPie en EPEL 8 y EPEL 9, pero no lo lista actualmente para EPEL 10. Comprueba el índice de paquetes de HTTPie antes de asumir que el paquete está disponible para tu release específico de Enterprise Linux.

Instalación con pipx (cuando tu distribución no lo empaqueta)

Si tu distribución no proporciona HTTPie, puedes instalarlo con pipx. Crea un entorno Python aislado para HTTPie y expone sus comandos en tu PATH, evitando conflictos con los paquetes Python gestionados por el sistema.

En Ubuntu o Debian:

sudo apt update
sudo apt install -y pipx
pipx ensurepath

En Fedora o una distribución compatible basada en DNF donde el paquete esté disponible:

sudo dnf install -y pipx
pipx ensurepath

Luego instala HTTPie:

pipx install httpie

💡 Si pipx ensurepath actualiza la configuración de tu shell, abre un terminal nuevo o sigue sus instrucciones para actualizar el PATH actual. En Rocky Linux o RHEL, la disponibilidad de pipx en sí depende de los repositorios habilitados.

Arch Linux

sudo pacman -Syu httpie

Verificar la instalación

Independientemente del método elegido, comprueba la versión y confirma que ambos comandos están disponibles:

http --version
https --version

Salida de ejemplo:

3.2.4
3.2.4

💡 Tu salida puede diferir según la fuente del paquete. Los ejemplos de esta guía apuntan a HTTPie 3.x, y la sintaxis JSON anidada del ejemplo de payloads anidados requiere HTTPie 3.0 o posterior. Si instalas un paquete de distribución más antiguo, comprueba su versión antes de ejecutar los ejemplos.

Comprobar estado y cabeceras de respuesta

Una de las tareas más comunes para un sysadmin es comprobar qué devuelve un servidor web. En este ejemplo, el servidor de laboratorio es 192.168.122.248 (también accesible como server1.tecmint.lan), con un servidor web escuchando en el puerto 80.

Ejecutar HTTPie con solo una URL envía una petición GET por defecto y muestra el estado, cabeceras y cuerpo de la respuesta:

http http://192.168.122.248/

Cuando estás diagnosticando caché, redirecciones o configuración del servidor, puede que solo necesites el estado y las cabeceras. Usa el flag -h (--headers) para mostrar las cabeceras sin el cuerpo. A diferencia de curl -I, que envía una petición HEAD, HTTPie sigue enviando una petición GET normal:

http -h http://192.168.122.248/

Salida de ejemplo:

HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 615
Content-Type: text/html
Date: Mon, 26 Oct 2026 06:40:12 GMT
ETag: "6714a2b1-267"
Last-Modified: Sun, 25 Oct 2026 10:12:33 GMT
Server: nginx/1.26.3

💡 Las cabeceras reales dependen del servidor y su configuración. Empieza por la línea de estado: 200 OK indica una petición exitosa, mientras que códigos como 301 o 302 indican redirecciones. El resto de cabeceras dan detalles sobre la respuesta: tipo de contenido, metadatos de caché e información del servidor cuando se expone.

Verbose: ver petición y respuesta

Cuando necesitas inspeccionar tanto la petición saliente como la respuesta entrante, usa -v (--verbose). Es útil para confirmar que una cabecera personalizada se envió correctamente:

http -v GET http://192.168.122.248/ User-Agent:tecmint-check/1.0

--print: seleccionar qué mostrar

Para una salida más precisa, usa --print (o -p) para seleccionar qué partes del intercambio muestra HTTPie:

Por ejemplo, para mostrar solo las cabeceras de petición y respuesta:

http -p Hh http://192.168.122.248/

💡 Esto es especialmente útil al depurar proxies inversos, comprobar cabeceras reenviadas o verificar cabeceras de autenticación personalizadas sin mostrar el cuerpo de la respuesta.

Redirecciones: control explícito

Por defecto, HTTPie no sigue redirecciones. Esto te permite inspeccionar la respuesta inicial al comprobar una redirección de HTTP a HTTPS o al diagnosticar un bucle de redirecciones. Para seguir redirecciones, añade --follow (o -F). Para mostrar también las respuestas intermedias, no solo la final, usa --all:

http --follow --all http://192.168.122.248/

Enviar datos JSON y parámetros de query a una API REST

Comprobar una página es solo parte de la prueba de API. A menudo necesitas enviar datos también. Aquí es donde HTTPie ahorra tecleo frente a curl: construye el cuerpo JSON a partir de asignaciones de campo legibles y establece automáticamente la cabecera Content-Type: application/json.

Para este ejemplo usaremos httpbin.org, un servicio público de pruebas que hace eco de los detalles de la petición para que puedas inspeccionar qué recibió el servidor. El siguiente comando envía dos campos string, un número y un booleano:

http POST https://httpbin.org/post name=web01 role=frontend port:=8080 enabled:=true

En la sección json de la respuesta deberías ver los datos enviados representados así:

{
  "enabled": true,
  "name": "web01",
  "port": 8080,
  "role": "frontend"
}

💡 Fíjate en que port llega como número y enabled como booleano. Esto demuestra la diferencia entre = y := que vimos antes. Si usas port=8080, HTTPie envía el valor como string JSON "8080" en lugar del número 8080.

Parámetros de query con ==

Los parámetros de query usan ==. HTTPie maneja la codificación URL, así que puedes pasar valores con espacios sin escaparlos manualmente:

http GET https://httpbin.org/get search=='disk full' limit==10

La petición incluye los parámetros search y limit. Puedes inspeccionar el campo url en la respuesta de httpbin para ver la URL resultante y cómo se codificaron los parámetros.

Form data con --form

Si una API espera form data en lugar de JSON, añade --form (o -f). HTTPie entonces envía los mismos ítems clave=valor como form data URL-encoded usando application/x-www-form-urlencoded:

http --form POST https://httpbin.org/post user=tecmint comment='Hello World'

En la respuesta, comprueba la sección form para ver los campos enviados.

💡 A diferencia de JSON, los valores form-encoded se transmiten como strings, así que este formato es apropiado cuando una API espera envíos de formularios HTML tradicionales.

Construir JSON anidado y previsualizar peticiones con --offline

El JSON plano del ejemplo anterior cubre muchas APIs, pero los payloads del mundo real a menudo contienen objetos y arrays anidados. Antes de HTTPie 3.0, construir estas estructuras a partir de ítems individuales era menos cómodo y a menudo requería pasar JSON crudo con :=.

HTTPie 3.0 introdujo la sintaxis JSON anidada, que te permite describir la estructura directamente usando corchetes en los nombres de campo.

Antes de enviar un payload complejo a una API real, es buena práctica previsualizar la petición. El flag --offline construye e imprime la petición sin enviarla por la red, permitiéndote inspeccionar primero el cuerpo JSON.

Por ejemplo, el siguiente comando crea un objeto network anidado con una dirección IP y un array de puertos numéricos, junto con un array de tags en el nivel superior:

http --offline --print=B POST https://httpbin.org/post \
    name=web01 \
    'network[ip]=192.168.122.248' \
    'network[ports][]:=80' \
    'network[ports][]:=443' \
    'tags[]=nginx' \
    'tags[]=production'

Salida:

{
    "name": "web01",
    "network": {
        "ip": "192.168.122.248",
        "ports": [
            80,
            443
        ]
    },
    "tags": [
        "nginx",
        "production"
    ]
}

Lo importante es cómo HTTPie interpreta los nombres de campo:

• network[ip] coloca la dirección IP dentro de un objeto network anidado.
• network[ports][] añade cada valor suministrado al array ports.
• tags[] añade valores a un array de nivel superior.
• := preserva los valores de puerto como números JSON en lugar de strings.

💡 Como --offline imprime automáticamente las cabeceras y el cuerpo de la petición, añadir --print=B reduce la salida al cuerpo. Esto mantiene el ejemplo centrado en el JSON generado y evita diferencias distractoras en cabeceras como Content-Length o User-Agent entre versiones de HTTPie.

Una vez que el payload se ve correcto, quita --offline y ejecuta el comando de nuevo para enviar la petición:

http POST https://httpbin.org/post \
    name=web01 \
    'network[ip]=192.168.122.248' \
    'network[ports][]:=80' \
    'network[ports][]:=443' \
    'tags[]=nginx' \
    'tags[]=production'

⚠️ Se requiere HTTPie 3.0 o posterior para esta sintaxis JSON anidada. Comprueba tu versión instalada con http --version si encuentras errores. La versión oficial cubre objetos anidados, arrays y previsualización offline de peticiones.

Autenticación: Basic Auth, tokens Bearer y sesiones

Hasta ahora, todas las peticiones han sido anónimas, pero la mayoría de las APIs del mundo real requieren autenticación. HTTPie soporta esquemas comunes de autenticación directamente y también puede guardar credenciales, cabeceras y cookies entre peticiones usando sesiones.

Autenticación Basic

Para HTTP Basic authentication, pasa el nombre de usuario a -a (--auth) y omite la contraseña. HTTPie te pedirá que la introduzcas antes de enviar la petición, manteniéndola fuera del comando:

http -a tecmint https://httpbin.org/basic-auth/tecmint/Secret123

Cuando se te pida, introduce Secret123. Una petición exitosa devuelve una respuesta similar a:

{
    "authenticated": true,
    "user": "tecmint"
}

💡 Introducir la contraseña en el prompt es más seguro que escribirla directamente en el comando, donde podría guardarse en el historial del shell o exponerse a través de los argumentos del proceso. Sin embargo, si usas una sesión, HTTPie puede guardar la contraseña introducida en su archivo de sesión (ver la advertencia de seguridad más abajo).

Token Bearer

Muchas APIs modernas usan bearer tokens en lugar de usuario y contraseña. Especifica el esquema de autenticación bearer con -A bearer y pasa el token usando -a.

Para este ejemplo, almacena un token de prueba en una variable de entorno en lugar de escribirlo directamente en el comando:

export API_TOKEN='your-token-here'
http -A bearer -a "$API_TOKEN" https://httpbin.org/bearer

HTTPie envía una cabecera Authorization: Bearer ... con la petición, y el endpoint de httpbin hace eco del resultado de la autenticación y de la información del token cuando la petición tiene éxito.

💡 Una variable de entorno evita colocar el token literal en el texto del comando, pero no es una solución completa de gestión de secretos. Dependiendo de tu sistema y permisos, las variables de entorno pueden ser accesibles a otros procesos o usuarios. Limpia la variable cuando termines de probar:

unset API_TOKEN

Reutilizar autenticación con sesiones

Cuando envías múltiples peticiones a la misma API, introducir las credenciales repetidamente se vuelve incómodo. Las sesiones de HTTPie te permiten persistir autenticación, cabeceras personalizadas y cookies entre peticiones al mismo host.

Crea una sesión nombrada añadiendo --session=lab a la primera petición:

http --session=lab -a tecmint https://httpbin.org/basic-auth/tecmint/Secret123

Introduce la contraseña cuando se te pida. HTTPie guarda la información de la sesión localmente.

Luego puedes reutilizar la sesión sin especificar las credenciales otra vez:

http --session=lab https://httpbin.org/basic-auth/tecmint/Secret123

HTTPie reutiliza la información de autenticación guardada y cualquier cabecera o cookie de sesión aplicable. La sesión nombrada está asociada al host, así que puede reutilizarse para otras peticiones a httpbin.org.

En Linux, los archivos de sesión nombrados suelen almacenarse bajo:

~/.config/httpie/sessions/<host>/<nombre>.json

Para este ejemplo, el archivo es:

~/.config/httpie/sessions/httpbin.org/lab.json

⚠️ Advertencia de seguridad: HTTPie almacena los datos de sesión, incluidas credenciales, contraseñas introducidas, cookies y cabeceras personalizadas, en texto plano. Protege los archivos de sesión contra accesos no autorizados y evita compartirlos o hacer commit de ellos en control de versiones. Comprueba los permisos del archivo y elimina las sesiones cuando ya no las necesites.

ls -l ~/.config/httpie/sessions/httpbin.org/lab.json
chmod 600 ~/.config/httpie/sessions/httpbin.org/lab.json
rm ~/.config/httpie/sessions/httpbin.org/lab.json   # cuando ya no la necesites

Subir y descargar archivos con HTTPie

La autenticación cubrió el envío de credenciales, y el siguiente trabajo común es mover archivos. La versión antigua de este artículo usaba el servicio público transfer.sh para esto, pero ese servicio ha cambiado de manos y ha pasado por varios anuncios de cierre a lo largo de los años, así que ya no es un ejemplo fiable. En su lugar, subiremos a httpbin y descargaremos desde nuestro propio servidor de laboratorio.

Subir un archivo como campo multipart

Para subir un archivo como campo de formulario multipart, como hace un formulario de subida del navegador, combina --form con el ítem campo@ruta de la sección de sintaxis:

echo "backup completed on $(hostname)" > report.txt
http --form POST httpbin.org/post report@report.txt

La sección files de la respuesta muestra el nombre del campo y el contenido del archivo que el servidor recibió. HTTPie también establece el Content-Type del archivo según su extensión.

Enviar un archivo como cuerpo crudo

También puedes enviar un archivo como cuerpo crudo de la petición, que es como muchas APIs aceptan subidas JSON o binarias. Usa redirección de entrada, y HTTPie envía el contenido del archivo tal cual:

http POST httpbin.org/post Content-Type:application/json < payload.json

Descargar archivos

Para descargas, el flag --download (-d) hace que HTTPie se comporte como wget. Guarda el cuerpo en un archivo, muestra una barra de progreso, y toma el nombre del archivo de la URL o de la cabecera Content-Disposition del servidor.

Para probarlo en el laboratorio, arranca un servidor web temporal en server1 que sirva el directorio actual en el puerto 8000:

python3 -m http.server 8000

💡 Si firewalld está corriendo en un servidor Rocky Linux, también necesitarás abrir el puerto 8000 temporalmente con:

sudo firewall-cmd --add-port=8000/tcp

Esto no es permanente y desaparece en el siguiente reload o reinicio.

De vuelta en tu máquina de administración, descarga un archivo de ese directorio:

http --download http://192.168.122.248:8000/report.txt

Usa --output (-o) para elegir un nombre de archivo distinto, y añade --continue (-c) junto con --output para reanudar una descarga grande que se interrumpió. Cuando termines, pulsa Ctrl+C en server1 para detener el servidor web temporal.

Usar HTTPie en scripts para comprobar la salud de servicios

Los ejemplos hasta ahora eran interactivos, pero HTTPie también es útil en scripts de shell y cron jobs, por ejemplo, para comprobar un endpoint de health después de un despliegue.

⚠️ Por defecto, HTTPie sale con estado 0 incluso cuando el servidor devuelve un error como 404 o 500, porque el intercambio HTTP en sí funcionó. Eso no es lo que un script quiere.

El flag --check-status lo arregla haciendo que HTTPie salga con un código basado en el estado HTTP:

Vamos a provocar deliberadamente un fallo con httpbin para verlo:

http --check-status --quiet httpbin.org/status/503
echo $?

Salida:

http: warning: HTTP 503 SERVICE UNAVAILABLE
5

La advertencia va a standard error, y el código de salida es 5, que un script puede comprobar.

--ignore-stdin: el flag que hace que HTTPie funcione en cron

Hay un flag más que importa en scripts. Cuando la entrada estándar no es un terminal, que es el caso en cron jobs y muchos sistemas de CI, HTTPie intenta leer el cuerpo de la petición de ella.

Cuando combinas entrada redirigida con ítems de datos de petición como clave=valor, HTTPie reporta un error porque cuerpos de petición crudos y datos de petición estructurados no pueden usarse juntos. El mensaje de error puede leerse así:

http: error: Request body (from stdin, --raw or a file) and request data (key=value) cannot be mixed

Sin ítems de petición, HTTPie puede esperar a la entrada estándar si no está conectada a un terminal y no se recibe una señal de fin de archivo. Añade --ignore-stdin cuando quieras evitar que HTTPie lea la entrada estándar:

http --ignore-stdin GET https://httpbin.org/get

Script completo de health check

Juntando todo esto, aquí tienes un pequeño script de health check. Créalo con nano en Ubuntu y Debian:

nano ~/check-web.sh

En Rocky Linux, AlmaLinux y RHEL, las instalaciones mínimas incluyen vi en lugar de nano, así que usa vi allí:

vi ~/check-web.sh

Luego añade el siguiente contenido al archivo:

#!/usr/bin/env bash
# ~/check-web.sh
# Check a web endpoint and report its HTTP status using HTTPie.

URL="${1:-http://192.168.122.248/}"

if http --check-status --ignore-stdin --quiet --timeout=5 GET "$URL"; then
    echo "OK: $URL is responding"
else
    code=$?
    echo "FAIL: $URL check failed with HTTPie exit code $code" >&2
    exit "$code"
fi

Guarda el archivo y sal del editor. Los flags de la línea http funcionan juntos así:

• --check-status convierte respuestas 3xx, 4xx y 5xx en códigos de salida no cero, para que el if pueda detectarlos.
• --ignore-stdin impide que HTTPie espere un cuerpo de petición en la entrada estándar, lo que mantiene el script funcionando bajo cron.
• --quiet suprime la salida normal, así el script solo imprime su propia línea OK o FAIL.
• --timeout=5 abandona después de 5 segundos sin respuesta, en lugar de colgarse en un servidor inalcanzable.

Haz el script ejecutable y ejecútalo contra el servidor de laboratorio, y luego contra una URL que devuelve error:

chmod +x ~/check-web.sh
~/check-web.sh
~/check-web.sh httpbin.org/status/404

Salida:

OK: http://192.168.122.248/ is responding
http: warning: HTTP 404 NOT FOUND
FAIL: httpbin.org/status/404 check failed with HTTPie exit code 4

💡 Cambia el valor por defecto de URL al endpoint de health de tu propio servidor. Como el servidor de laboratorio obtiene su dirección por DHCP, reserva o configura una dirección estática primero, para que la IP hardcodeada siga apuntando a la máquina correcta.

Consejos profesionales para usar HTTPie de forma segura y eficiente

Con HTTPie corriendo interactivamente y en scripts, algunas configuraciones hacen el uso diario más fluido y seguro, especialmente cuando pruebas servicios internos.

Configuración por defecto en config.json

Si te encuentras añadiendo los mismos flags a cada comando (un estilo de color concreto, seguir redirecciones siempre, etc.), puedes establecerlos como valores por defecto en el archivo de configuración de HTTPie. Ábrelo con nano en Ubuntu y Debian:

mkdir -p ~/.config/httpie
nano ~/.config/httpie/config.json

En Rocky Linux, AlmaLinux y RHEL, usa vi:

mkdir -p ~/.config/httpie
vi ~/.config/httpie/config.json

Añade la siguiente configuración. JSON no permite comentarios, así que la ruta del archivo se da aquí en lugar de en la primera línea: ~/.config/httpie/config.json.

{
    "default_options": [
        "--style=monokai",
        "--follow",
        "--timeout=10"
    ]
}

Guarda el archivo y sal del editor. Las opciones se aplican a cada comando http y https:

• --style=monokai establece el esquema de color para la salida del terminal. Ejecuta http --help y mira la opción --style para ver los estilos disponibles en tu versión.
• --follow sigue redirecciones automáticamente, lo cual viene bien para probar APIs pero oculta redirecciones que quizá quieras ver al comprobar reglas del servidor.
• --timeout=10 evita que las peticiones se cuelguen para siempre en un host inalcanzable.

💡 Ajusta la lista a tus propios hábitos. Para un solo comando, aún puedes sobrescribir un valor por defecto, por ejemplo añadiendo --style=auto.

Seguridad: nunca escribas contraseñas en la línea de comandos

Evita escribir contraseñas y tokens directamente en la línea de comandos, ya que acaban en el historial del shell y son visibles para otros usuarios a través de ps mientras el comando corre. En su lugar, usa el prompt de contraseña de -a usuario, una variable de entorno, o un archivo de sesión con permisos restringidos.

Certificados autofirmados: usa --verify, no desactives la verificación

Los servidores internos a menudo usan certificados autofirmados, y HTTPie los rechazará con un error de verificación de certificado SSL. En lugar de desactivar la verificación con --verify=no, apunta HTTPie a tu CA interna con --verify=/ruta/a/ca.crt, lo que mantiene la protección contra un man-in-the-middle mientras sigue confiando en tus propios certificados.

# ❌ Mal: desactiva toda la verificación
http --verify=no https://internal.example.com/api

# ✅ Bien: confía en tu CA interna sin perder protección
http --verify=/etc/ssl/certs/internal-ca.crt https://internal.example.com/api

Usa HTTPie 3.2.4 o posterior

⚠️ Asegúrate de que estás ejecutando HTTPie 3.2.4 o posterior, porque la versión 3.2.2 tenía un problema conocido con la validación de certificados SSL, y 3.2.4 corrigió cómo se cargan los certificados por defecto.

Redirección de salida: HTTPie formatea solo cuando imprime a un terminal

💡 Recuerda que HTTPie formatea la salida JSON solo cuando imprime a un terminal. Cuando rediriges la salida a un archivo o la canalizas a otro comando, HTTPie envía el cuerpo crudo, que suele ser lo que quieres para herramientas como jq. Añade --pretty=all si quieres guardar la versión formateada en su lugar.

# Cuerpo crudo, ideal para jq
http GET https://httpbin.org/get | jq '.headers'

# Cuerpo formateado guardado en archivo
http --pretty=all GET https://httpbin.org/get > respuesta.json

Conclusión

HTTPie convierte el trabajo HTTP cotidiano en comandos cortos y legibles, con cuerpos JSON automáticos, salida legible, autenticación integrada, sesiones y descargas. Con --check-status y --ignore-stdin, la misma herramienta también funciona de forma fiable en scripts y cron jobs para health checks tras despliegues.

🎁 Anexo: mejoras y actualizaciones sugeridas en esta versión

Añadidas a esta traducción, fruto del análisis del artículo original:

• Tabla de separadores al inicio (=, :=, ==, :, @, =@, :=@): el original los describe en prosa, pero convertirlos en tabla reduce a la mitad el tiempo de aprendizaje de la sintaxis de HTTPie.
• Resumen visual de separadores justo debajo de la tabla: un bloque de texto que puedes copiar y tener a mano mientras escribes comandos, sin volver a la sección teórica.
• Tabla de códigos de salida de --check-status (2 = timeout, 1 = conexión rechazada, 3/4/5 = redirección/4xx/5xx): el original menciona solo 3, 4 y 5 de pasada; los códigos 1 y 2 son críticos en scripts reales y merecen una tabla.
• Comando chmod 600 y rm para archivos de sesión: el original dice “protege los archivos de sesión” pero no muestra cómo hacerlo, lo que deja la advertencia a medias.
• Ejemplo comparativo --verify=no vs --verify=/ruta/ca.crt: el original lo menciona en prosa; el ejemplo explícito deja claro por qué desactivar la verificación es mala idea incluso en servidores internos.
• Ejemplo de --pretty=all con jq: el original solo dice “añade --pretty=all si quieres la versión formateada”; falta el caso de uso real (guardar respuesta formateada en archivo) que justifica el flag.
• Comandos con firewall-cmd --add-port=8000/tcp mostrados como bloque de código en lugar de en prosa: el original lo mete en una nota con un guion mal renderizado (–add-port), que puede confundir al copiar y pegar.
• Advertencia de EPEL 10 destacada: HTTPie no está listado en EPEL 10 actualmente, lo cual es un problema real para quien instala en RHEL 10 / Rocky 10 / Alma 10 y asume que el paquete estará.
• Nota sobre --offline --print=B explicada con el motivo real (evitar diferencias de Content-Length y User-Agent entre versiones), que en el original se menciona de pasada y es la razón por la que los ejemplos son reproducibles.
• Sugerencia añadida: http --session=lab --session-read-only=lab para reutilizar una sesión sin modificarla al hacer peticiones de solo lectura, útil en scripts de monitorización.
• Sugerencia añadida: http --chunked para subidas grandes sin Content-Length, útil al enviar streams a APIs que lo soportan.
• Sugerencia añadida: http --stream para consumir respuestas chunked o de larga duración (SSE, logs en vivo) sin esperar a que termine la respuesta completa.
• Sugerencia añadida: httpie cli plugins list (el comando introducido en HTTPie 3.x) para gestionar plugins, que el original menciona en la introducción pero nunca muestra en uso.
• Sugerencia añadida: comparación rápida HTTPie vs xh vs curlie para quien llega desde el tutorial anterior y quiere saber cuándo cambiar de herramienta:
  • HTTPie: si ya tienes Python y quieres el ecosistema completo con plugins y sesiones.
  • xh: si quieres la misma sintaxis sin Python (binario único Rust) o en contenedores mínimos.
  • curlie: si quieres sintaxis HTTPie con todas las opciones de curl disponibles.
• Orden de aprendizaje recomendado: separadores → ejemplo GET simple → POST con JSON → := para números/booleanos → --offline para payloads anidados → sesiones → --check-status en scripts. Este orden evita el error clásico de lanzarse a la sintaxis anidada sin dominar antes = y :=.