Mejores herramientas CLI ligeras para pruebas de API

La mayoría de las herramientas de prueba de API quieren que abras una ventana, inicies sesión y hagas clic en un espacio de trabajo antes de que puedas enviar una sola solicitud. Eso está bien para una primera vista. Es la forma incorrecta para la terminal, donde quieres escribir una línea, leer la respuesta y seguir adelante. Las herramientas de línea de comandos ligeras invierten el orden: la herramienta se quita de en medio y la solicitud es toda la interacción.

Ligero aquí significa algo específico. Una instalación pequeña, a menudo un solo binario o un `npx` rápido. Inicio rápido, para que acceder a un endpoint se sienta instantáneo. Poca o ninguna configuración para ejecutar la primera solicitud. Salida orientada a la terminal que puedes canalizar a `jq` o grep. Esta es una pregunta diferente a "qué herramienta es de código abierto" o "cuál tiene más características". Se trata de huella y fricción. Para una visión más amplia que también cubre GUI alojadas, consulta el resumen de las mejores herramientas gratuitas de prueba de API.

A continuación se presentan ocho herramientas CLI ligeras para probar API REST y HTTP, ordenadas aproximadamente de las más pequeñas y manuales a las que ejecutan suites de pruebas completas en CI. Cada entrada tiene un comando de instalación real, un comando que muestra cómo funciona, para qué es mejor y un límite honesto. La última, la CLI de Apidog, es el binario ligero que ejecuta los escenarios que construyes visualmente y controla un pipeline según su código de salida.

Qué hace que una herramienta CLI sea “ligera” para la prueba de API

Muchas herramientas se ejecutan en una terminal. No todas se sienten ligeras. Para esta lista, una herramienta califica en cuatro puntos:

• Pequeña huella. Un solo binario, una instalación con `pip`/`npm`, o una línea con `npx`. Sin entorno de ejecución que debas configurar primero, idealmente sin demonio.
• Inicio rápido. La herramienta se inicia y envía la solicitud sin un calentamiento. Los binarios de Rust y Go ganan aquí; cualquier cosa que arranque un entorno de ejecución pesado pierde.
• Configuración baja o nula. Puedes enviar la primera solicitud sin archivo de proyecto, sin cuenta, sin iniciar sesión. La configuración es opcional, para cuando quieras guardar y repetir.
• Salida nativa de la terminal. Los resultados se imprimen en un formato que puedes leer de un vistazo y canalizar a otro comando. Los códigos de salida significan algo, por lo que CI puede usarlos como puerta.

Las herramientas se basan en los tres primeros; las dos últimas se apoyan en el cuarto, porque ahí es donde un binario ligero se gana su lugar en un pipeline. Si quieres profundizar en el lado interactivo de "acceder a un endpoint manualmente", la guía de alternativas a curl para pruebas de API REST profundiza en los clientes manuales.

curl: la base que ya está instalada

curl es la herramienta que casi con toda seguridad ya tienes. Viene en macOS, la mayoría de las distribuciones de Linux y Windows moderno, por lo que la instalación más ligera es no instalar nada. Habla HTTP, HTTPS y una larga lista de otros protocolos, y es la referencia con la que se compara cualquier otro cliente.

# Already on your machine; check the version
curl --version

# POST JSON and print only the HTTP status
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"user":"acme","plan":"pro"}'

Mejor para: solicitudes rápidas únicas, scripts y cualquier entorno donde no puedas instalar nada nuevo. Límite honesto: la ergonomía es anticuada. Configuras los encabezados manualmente, JSON no se imprime bonito y afirmar sobre una respuesta significa canalizar a `jq` y verificar un código de salida tú mismo. Envía y muestra; no prueba.

HTTPie: curl para humanos

HTTPie realiza las mismas solicitudes que curl, con una sintaxis diseñada para personas. El comando es `http`, los encabezados y campos JSON son pares simples `clave=valor`, y la salida está coloreada y formateada por defecto. Está escrito en Python, por lo que necesita un entorno de ejecución de Python, lo que lo hace más pesado que un solo binario pero sigue siendo una instalación de una línea.

python -m pip install httpie   # or: brew install httpie

# POST JSON: age:=24 sends a number, name= sends a string
http POST httpbin.org/post name=acme age:=24 plan=pro

Mejor para: explorar una API manualmente cuando quieres una salida legible sin flags. Límite honesto: el inicio de Python es notablemente más lento que un binario compilado, e instalarlo en un sistema limpio significa instalar Python si no está presente. Al igual que curl, es un cliente, no un ejecutor de pruebas; lees la respuesta, no la afirmas.

xh: la velocidad de HTTPie en un solo binario

xh reimplementa la sintaxis amigable de HTTPie en Rust y se distribuye como un único binario enlazado estáticamente. Obtienes la misma ergonomía `clave=valor` y salida coloreada, con un inicio más rápido y nada que instalar más allá del propio binario. Soporta HTTP/2 e incluso puede imprimir el comando curl equivalente con `--curl`.

brew install xh   # or: cargo install xh --locked

# Same syntax as HTTPie, faster start
xh POST httpbin.org/post name=acme age:=24 plan=pro

Mejor para: desarrolladores a quienes les gusta la sensación de HTTPie pero quieren un único binario rápido sin entorno de ejecución. Límite honesto: no implementa todas las características de HTTPie, y no hay un sistema de plugins. Es más joven que HTTPie, por lo que el ecosistema a su alrededor es más pequeño. Sigue siendo un cliente, no un motor de aserciones.

Hurl: pruebas de texto plano que se ejecutan en CI

Hurl es donde esta lista pasa de "enviar una solicitud" a "probar una respuesta". Ejecuta solicitudes HTTP escritas en un archivo `.hurl` de texto plano y realiza aserciones sobre los resultados. Está escrito en Rust, impulsado por libcurl bajo el capó, y se distribuye como un único binario sin entorno de ejecución. Las pruebas se leen casi como las propias solicitudes, lo que las hace fáciles de revisar en una solicitud de extracción.

brew install hurl   # or: cargo install --locked hurl

cat > login.hurl <<'EOF'
POST https://httpbin.org/post
{ "user": "acme", "plan": "pro" }

HTTP 200
[Asserts]
jsonpath "$.json.user" == "acme"
EOF

hurl --test login.hurl   # non-zero exit if an assertion fails

Mejor para: comprobaciones de estilo contractual y pruebas de humo que mantienes en control de versiones como texto legible. El flag `--test` lo convierte en una puerta de CI limpia; una aserción fallida devuelve un código de salida distinto de cero. Límite honesto: está enfocado en HTTP, por lo que no manejará gRPC ni generará carga real. Los flujos complejos significan más archivos `.hurl` en lugar de un lenguaje de scripting.

Step CI: un archivo YAML para un flujo de varios pasos

Step CI ejecuta flujos de trabajo de API descritos en un único archivo YAML. Cubre REST, GraphQL, gRPC, tRPC y SOAP en un solo flujo de trabajo, y puede validar contra un esquema OpenAPI. Lo instalas desde npm y ejecutas el mismo archivo localmente y en CI. Se lee bien cuando una prueba es realmente una secuencia: iniciar sesión, capturar un token, usarlo en la siguiente llamada, verificar el resultado.

npm install -g stepci

# workflow.yml describes steps, captures, and checks
stepci run workflow.yml

Mejor para: equipos que quieren un archivo declarativo que describa un flujo de API de varios pasos, ejecutado de forma idéntica en un portátil y en un pipeline. Límite honesto: es un paquete de Node, por lo que es más pesado que un binario de Rust o Go, y lleva un entorno de ejecución. El ritmo de lanzamiento se ha ralentizado, así que verifica la actividad reciente del repositorio antes de construir un pipeline sobre él. Para ver cómo estas piezas encajan en un plan de pruebas más completo, consulta las estrategias de prueba de API.

k6: pruebas de carga ligeras desde la terminal

k6 responde a una pregunta diferente: no "es correcta esta respuesta" sino "soporta la carga". Está escrito en Go, se distribuye como un único binario estático y los scripts son JavaScript plano. Está construido para un uso mínimo de recursos, por lo que puedes enviar tráfico real desde un portátil. Los umbrales convierten una prueba de carga en una puerta de paso/fallo; si se supera uno, k6 sale con el código 99, que un pipeline interpreta como un fallo.

brew install k6   # or run via Docker: docker run grafana/k6

cat > load.js <<'EOF'
import http from 'k6/http';
import { check } from 'k6';
export const options = {
  vus: 10, duration: '30s',
  thresholds: { http_req_duration: ['p(95)<500'] },
};
export default function () {
  const res = http.get('https://httpbin.org/get');
  check(res, { 'status is 200': (r) => r.status === 200 });
}
EOF

k6 run load.js

Mejor para: comprobaciones de rendimiento y carga que deseas programar y ejecutar en CI sin levantar un clúster. Límite honesto: es una herramienta de carga, no un cliente de prueba funcional; no lo usarías para ver una sola respuesta. Escribir escenarios significativos implica aprender su API de JavaScript.

Newman: ejecutar una colección de Postman sin interfaz gráfica

Newman es el ejecutor de línea de comandos para las colecciones de Postman. Si tu equipo ya crea solicitudes y pruebas en Postman, Newman ejecuta esa misma colección desde una terminal sin GUI, que es lo que necesitas en CI. Exportas la colección (y opcionalmente un entorno) como JSON y le indicas a Newman dónde está.

npm install -g newman

# collection.json exported from Postman; -e passes an environment
newman run collection.json -e staging.json

Mejor para: equipos que invierten en Postman y quieren que sus colecciones existentes se ejecuten sin interfaz gráfica en un pipeline. Newman devuelve un código de salida distinto de cero cuando una prueba falla, por lo que bloquea CI limpiamente. Límite honesto: es un paquete de Node, y solo ejecuta colecciones con formato Postman, por lo que es más útil si ya estás en ese ecosistema. Ejecuta pruebas que alguien construyó en una GUI; la autoría sigue ocurriendo allí.

CLI de Apidog: ejecuta los escenarios que construiste, controla CI según el código de salida

La CLI de Apidog es el extremo ligero de Apidog. Es un paquete npm, `apidog-cli`, que ejecuta los escenarios de prueba que diseñaste visualmente en Apidog directamente desde una terminal. La parte de construir una prueba permanece en la GUI, donde encadenar solicitudes, extraer variables y escribir aserciones es rápido; la CLI es la pequeña pieza que ejecuta uno de esos escenarios sin interfaz gráfica y te devuelve un código de salida. Apidog no es de código abierto, pero su nivel gratuito más esta CLI te ofrece una alternativa integrada para unir un cliente, un ejecutor y una herramienta de carga separados.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>

# Copy the exact command from your scenario's CI/CD tab
apidog run -t <scenario_id> -e <env_id> -r cli

No adivines los ID de escenario y entorno. Abre tu escenario de prueba en Apidog, ve a la pestaña CI/CD y copia el comando `apidog run` generado con los ID ya completados. El reportero `-r cli` imprime un resultado paso a paso y un resumen en la terminal; agrega `-r cli,junit` cuando un panel de CI necesite analizar los resultados. Al igual que las herramientas anteriores, `apidog run` sale con `0` cuando todas las aserciones pasan y con un valor distinto de cero cuando algo falla, por lo que un pipeline lo trata como una puerta limpia. Su salida es JSON estructurado con `agentHints.nextSteps`, lo que facilita que un agente de codificación de IA también lo ejecute y lo lea.

Mejor para: equipos que desean crear escenarios complejos y de varios pasos en un editor visual pero ejecutarlos sin interfaz gráfica en CI o desde un agente. Límite honesto: a diferencia de curl o xh, está vinculado a escenarios que mantienes en un proyecto de Apidog, por lo que es la opción de plataforma integrada, no un cliente HTTP básico. Para el conjunto completo de comandos, consulta la guía completa de la CLI de Apidog, la referencia del comando apidog run y el tutorial sobre cómo probar una API REST desde la línea de comandos con la CLI de Apidog.

Cómo elegir

La herramienta adecuada depende de cuán lejos necesites ir más allá de "enviar una solicitud".

Empieza por arriba para el trabajo manual. Usa curl o xh para acceder a un endpoint. Pasa a Hurl cuando quieras que esas comprobaciones se ejecuten en control de versiones. Incluye k6 cuando la pregunta se refiera a la carga, y Newman si tus pruebas ya están en Postman. Elige la CLI de Apidog cuando prefieras construir un escenario complejo en un editor y ejecutarlo sin interfaz gráfica en cualquier otro lugar. Si estás sopesando estas opciones frente a un flujo de trabajo completo sin GUI, la guía de herramientas de prueba de API sin interfaz gráfica cubre la ejecución de pruebas sin ninguna interfaz.

Dónde las herramientas ligeras son útiles

Las herramientas CLI ligeras ganan en los mismos días en que una GUI te ralentiza: cuando estás inmerso en una terminal, cuando una prueba necesita ejecutarse en CI sin intervención humana, y cada vez más, cuando un agente de IA realiza la verificación por ti. curl y xh mantienen el ciclo manual ajustado. Hurl y Step CI convierten las solicitudes ad-hoc en pruebas repetibles. k6 responde a la pregunta de la carga. Newman ejecuta lo que ya construiste en Postman.

La CLI de Apidog cierra la brecha entre la creación de una prueba y su ejecución en cualquier lugar. Diseñas el escenario una vez en Apidog, luego `apidog run` lo dispara desde una terminal, un pipeline o un agente, y el código de salida decide si la compilación permanece en verde. Descarga Apidog, construye un escenario e inserta su comando `apidog run` en tu configuración de CI para ver cómo se cierra todo el ciclo.