Mejores herramientas CLI ligeras para desarrollo

La mayor parte del día de un desarrollador backend se compone de bucles pequeños y rápidos. Lanzar una solicitud a un endpoint, leer el JSON, ajustar, repetir. Si utilizas una GUI pesada para eso, pasarás más tiempo esperando a que cargue que haciendo el trabajo.

Las herramientas CLI ligeras cambian eso. Se distribuyen como un único binario o un paquete instalable con npx, arrancan en mucho menos de un segundo y realizan una única tarea sin un asistente de configuración. Las integras en scripts de shell y trabajos de CI, y no se interponen en tu camino. Para el trabajo de API y backend, un pequeño conjunto de estas herramientas cubre la mayor parte del ciclo: enviar solicitudes, analizar respuestas, exponer un puerto local y ejecutar tu suite de pruebas.

Esta guía selecciona diez que se ganan un lugar en la PATH de un desarrollador backend. Cada sección muestra el comando que demuestra su funcionamiento. El tema es la huella: lo que se instala rápido, arranca rápido y pide casi nada antes de ser útil. Para una visión más amplia de cómo encajan estas herramientas, la guía de desarrollo de API establece el contexto.

button

Qué hace que una herramienta CLI sea "ligera" para el desarrollo

Lo ligero se trata de la huella y la fricción, no de cuántas características incluye una herramienta. Cuando decidas qué incluir en tu conjunto, considera cuatro cosas:

Tamaño y forma de la instalación. Un único binario estático o un pequeño paquete de npx supera a cualquier cosa que arrastre un tiempo de ejecución y un archivo de bloqueo.
Velocidad de inicio. La herramienta debe estar funcionando antes de que hayas vuelto a tu editor. Los binarios de Rust y Go arrancan en frío en milisegundos, lo cual es importante cuando los llamas en un bucle.
Configuración hasta el primer resultado. Configuración cero hasta un valor predeterminado útil es el estándar. Si necesita primero un archivo de proyecto, una cuenta y un panel de control, no es ligera.
Componibilidad. Lee stdin, escribe stdout, establece un código de salida real y se conecta a la siguiente herramienta. Eso es lo que hace que una herramienta pequeña valga más de lo que ocupa.

Las herramientas a continuación van aproximadamente desde las más pequeñas y de un solo propósito hasta las más completas. curl ya está en tu máquina; el resto se instalan rápidamente.

curl

curl es el punto de referencia con el que se mide cualquier otra herramienta HTTP. Ya está en casi todas las máquinas, habla todos los protocolos que utilizarás y hace exactamente lo que le dices. Para una verificación rápida de que un endpoint está activo, no hay nada más rápido a lo que recurrir.

curl -s -X POST https://api.github.com/repos/curl/curl/issues \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Test issue"}'

El -s silencia el medidor de progreso para que la respuesta se redirija limpiamente. Añade -i para ver los encabezados, -w '%{http_code}' para imprimir solo el código de estado, y --fail para que curl devuelva una salida no cero en caso de 4xx o 5xx, que es lo que deseas dentro de una verificación de CI.

Ideal para: scripting, verificaciones de estado de CI y cualquier solicitud que quieras copiar, pegar y compartir. Un comando curl funciona en la máquina de cualquier compañero de equipo.

Límites honestos: la sintaxis de las banderas es densa y el manejo del cuerpo JSON es manual. Para solicitudes interactivas rápidas, las dos herramientas siguientes son más amigables.

HTTPie

HTTPie (http) es curl con los bordes afilados pulidos, diseñado para que los humanos escriban solicitudes a mano. JSON es el formato predeterminado, la salida está coloreada y formateada, y construyes una solicitud a partir de elementos simples clave=valor en lugar de recordar banderas.

http POST httpbin.org/post name=apidog role=api-tool active:=true

Eso envía un cuerpo JSON de {"name": "apidog", "role": "api-tool", "active": true}. El = establece una cadena, := establece un valor JSON en crudo, y encabezado:valor establece un encabezado. Sin comillas en un blob JSON, sin la gestión de -H y -d. La respuesta se devuelve formateada legiblemente.

Ideal para: exploración interactiva de API donde la legibilidad es clave.

Límites honestos: es un paquete de Python, por lo que arranca en frío más lento que un binario nativo y necesita Python en la máquina. Si la velocidad de inicio importa, usa xh.

xh

xh es la sintaxis de HTTPie en un único binario de Rust. Reimplementa el estilo de elementos de solicitud de HTTPie, por lo que name=value y := funcionan igual, pero se distribuye como un único archivo enlazado estáticamente sin tiempo de ejecución y arranca aproximadamente un 30% más rápido. También es compatible con HTTP/2 y HTTP/3.

xh POST httpbin.org/post name=apidog age:=24

La misma ergonomía que HTTPie, inicio casi instantáneo. Debido a que es un único binario sin dependencias, se integra en una imagen CI ligera o un contenedor sin arrastrar Python consigo. El proyecto xh en GitHub distribuye binarios precompilados para Linux, macOS y Windows.

Ideal para: desarrolladores que les gusta la sensación de HTTPie pero quieren velocidad nativa y una instalación sin dependencias para scripts y contenedores.

Límites honestos: cubre la superficie común de HTTPie, no todos los plugins. Para casi todo el trabajo de solicitud, esa brecha nunca se nota.

jq

jq hace que cualquier otra herramienta HTTP sea más útil. Es un único binario que filtra y reformatea JSON en la línea de comandos, para que puedas extraer un campo de una respuesta de API en lugar de revisar todo el bloque.

curl -s https://api.github.com/repos/stedolan/jq | jq '.stargazers_count'

Eso imprime solo el número de estrellas. jq tiene un lenguaje de consulta completo: .items[] | .name itera sobre un array, select(.active) filtra, y -r da una salida en crudo sin comillas para que puedas redirigirla a una variable de shell. Es el pegamento entre una llamada de API y el resto de tu script.

Ideal para: extraer y transformar campos de respuestas JSON en scripts y CI.

Límites honestos: la sintaxis de consulta tiene una curva de aprendizaje, y las transformaciones profundamente anidadas se vuelven crípticas. Para un acceso simple a campos es trivial.

gh (GitHub CLI)

gh lleva la API de GitHub a tu terminal sin que tengas que escribir una sola llamada curl contra ella. Maneja la autenticación una sola vez a través de gh auth login, luego envuelve las pull requests, issues, releases y repositorios en comandos sencillos. Para los equipos de backend cuyo flujo de despliegue y revisión se realiza en GitHub, elimina una pestaña del navegador del ciclo.

gh pr create --title "Add rate limiting" --body "Closes #42" --base main

Eso abre una PR desde tu rama actual. gh pr checks observa CI, gh run watch sigue un flujo de trabajo en vivo, y gh api te proporciona un cliente autenticado y paginado para cualquier endpoint que los comandos envueltos no cubran.

Ideal para: programar GitHub en sí mismo: abrir PRs desde CI, crear versiones y consultar la API sin gestionar tokens manualmente.

Límites honestos: es solo para GitHub, por lo que una tienda de GitLab o Bitbucket no obtiene nada de ello.

ngrok

ngrok expone un puerto local a una URL pública a través de un túnel seguro. ¿Estás construyendo un manejador de webhooks o necesitas que alguien acceda a tu servidor de desarrollo desde fuera de tu red? Convierte localhost en un enlace compartible con un solo comando. El agente es un binario sin dependencias que se ejecuta en cualquier lugar.

ngrok http 8080

Eso reenvía una URL pública https:// a tu puerto local 8080 y la imprime en la terminal. También ejecuta un inspector de tráfico en http://127.0.0.1:4040 donde puedes reproducir cada solicitud que llegó, lo que es un verdadero ahorrador de tiempo cuando depuras un webhook de pago o Git que no controlas.

Ideal para: desarrollo de webhooks, compartir un trabajo en progreso con un compañero de equipo y probar callbacks de terceros contra código local.

Límites honestos: es un servicio comercial con un nivel gratuito; el plan gratuito rota tu URL en cada sesión y limita su velocidad. Para HTTPS local estable con un nombre fijo, usa mkcert en su lugar.

mkcert

mkcert crea certificados HTTPS de confianza local sin configuración. Escrito en Go por Filippo Valsorda, es un único binario que crea una autoridad de certificación local, la instala en los almacenes de confianza de tu sistema y emite certificados que tu navegador acepta sin advertencias. Así es como ejecutas https://localhost localmente sin el temido candado rojo.

mkcert -install
mkcert localhost 127.0.0.1 myapp.local

La primera línea configura la CA local una sola vez. La segunda emite un certificado y una clave para los nombres que enumeres, listos para entregar a tu servidor de desarrollo o proxy inverso. Sin encantamientos de OpenSSL, sin el certificado autofirmado que ignoras en cada recarga. Probar redirecciones OAuth, cookies seguras o cualquier cosa que se comporte de manera diferente a través de HTTPS se vuelve mucho más fácil.

Ideal para: obtener HTTPS real y de confianza en un entorno de desarrollo local para que coincida con producción.

Límites honestos: es solo para desarrollo. Nunca uses certificados mkcert en producción, y protege la clave de la CA raíz que genera; puede firmar para cualquier nombre en tu máquina.

watchexec

watchexec vuelve a ejecutar un comando cada vez que cambian los archivos. Es un único binario de Rust que observa un directorio y reinicia tu servidor o vuelve a ejecutar tus pruebas en el momento en que guardas. Respeta .gitignore por defecto, por lo que no se activará con artefactos de construcción.

watchexec -e py -r 'pytest tests/'

El -e py filtra los archivos Python, y -r reinicia un proceso de larga duración en lugar de apilar nuevos. Apúntalo a cualquier comando: watchexec -r 'go run .' para un servidor Go, watchexec 'npm test' para una suite JS. Es agnóstico al lenguaje, por lo que una herramienta cubre cada proyecto en lugar de un observador por pila.

Ideal para: ciclos rápidos de edición y ejecución en un servidor local o suite de pruebas, sin un modo de observación específico del framework.

Límites honestos: observa y vuelve a ejecutar; no hace recarga en caliente de módulos ni preserva el estado en proceso.

Docker CLI

El Docker CLI es la herramienta más pesada aquí, y se gana su lugar. Cuando necesitas un Postgres real, Redis o una dependencia completa para el desarrollo local, un docker run te da una instancia desechable para eliminar cuando hayas terminado. Sin instalación a nivel de sistema, sin servicios sobrantes.

docker run --rm -e POSTGRES_PASSWORD=dev -p 5432:5432 postgres:16

El --rm elimina el contenedor al salir, -e establece la contraseña y -p mapea el puerto a tu host. Tu aplicación se conecta a localhost:5432 y obtienes una base de datos limpia en cada ejecución. Cambia postgres:16 por redis:7 o cualquier imagen y el patrón se mantiene.

Ideal para: iniciar servicios de soporte para desarrollo local y pruebas de integración, de forma reproducible, sin contaminar tu máquina.

Límites honestos: no es ligero en el sentido binario; necesita un demonio en ejecución y recursos reales de disco y memoria. Pero el CLI es programable y orientado a la terminal, y para una infraestructura local reproducible, nada más se le acerca.

apidog-cli

Una vez que estás trabajando con API en la línea de comandos, la pieza que falta es tu proyecto API real: sus endpoints, esquemas, entornos y escenarios de prueba. Apidog distribuye apidog-cli, el CLI ligero que conecta la terminal con ese proyecto. Se instala como un paquete npm y te ofrece una ruta programable para diseñar, importar, simular y probar recursos sin abrir la aplicación de escritorio.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run -t <scenario_id> -e <env_id> -r cli

apidog run ejecuta un escenario de prueba guardado contra un entorno e imprime un resultado paso a paso en la terminal. Sale con 0 cuando todas las aserciones pasan y con un valor distinto de cero en caso de fallo, por lo que se integra directamente en una puerta de CI. Más allá de las pruebas, el CLI cubre grupos de comandos reales: endpoint y schema para el diseño, import y export para mover especificaciones (OpenAPI, Swagger, Postman) de entrada y salida, mock para las expectativas de simulación, y environment y variables para la configuración. La salida es JSON estructurado con agentHints.nextSteps, por lo que también encaja con asistentes de codificación de IA que desarrollan API. Para la referencia de comandos completa, consulta la guía completa de Apidog CLI; la guía de instalación de Apidog CLI te guía a través de la primera ejecución.

Ideal para: ejecutar tus escenarios de prueba en CI y gestionar recursos del proyecto desde scripts, especialmente en un flujo de trabajo de desarrollo de API 'spec-first' donde el contrato impulsa todo.

Nota honesta: Apidog no es de código abierto; es un producto comercial con un nivel gratuito. Pero ese nivel gratuito más el CLI te ofrecen una alternativa integrada a unir tú mismo un cliente de solicitudes, un servidor de simulación y un ejecutor de pruebas, todo respaldado por un solo proyecto. La pieza ligera es el binario apidog-cli; la plataforma completa de Apidog es una GUI sobre el mismo proyecto.

Cómo elegir

La mayoría de estas herramientas son complementarias, no competidoras. Es probable que utilices varias: un cliente HTTP, jq, un túnel, un observador y un ejecutor de pruebas.

Herramienta	Ideal para	Instalación	¿Código abierto?
curl	Solicitudes con scripts, verificaciones de estado de CI	preinstalado	Sí (licencia curl)
HTTPie	Solicitudes interactivas legibles	`pip install httpie`	Sí (BSD)
xh	Estilo HTTPie, velocidad nativa	`cargo install xh` / binario	Sí (MIT)
jq	Filtrar respuestas JSON	`brew install jq` / binario	Sí (MIT)
gh	Programar PRs y CI de GitHub	`brew install gh` / binario	Sí (MIT)
ngrok	Exponer localhost, webhooks	descargar binario	No (freemium)
mkcert	Certificados HTTPS locales de confianza	`brew install mkcert` / binario	Sí (BSD)
watchexec	Volver a ejecutar al cambiar archivos	`cargo install watchexec-cli`	Sí (Apache-2.0)
Docker CLI	Servicios de soporte desechables	instalación de Docker	Sí (Apache-2.0)
apidog-cli	Ejecutar escenarios de prueba, gestionar proyectos	`npm install -g apidog-cli`	No (freemium)

Elige según la tarea. Enviar solicitudes: xh o HTTPie para trabajo interactivo, curl para scripts. Leer respuestas: siempre jq. Exponer un puerto: ngrok. HTTPS local: mkcert. Volver a ejecutar al guardar: watchexec. Servicios de soporte: Docker. Ejecutar tus pruebas de API y gestionar el proyecto: apidog-cli.

Conclusión

Un buen conjunto de herramientas ligeras es un puñado de herramientas pequeñas y rápidas que hacen una cosa cada una y se conectan entre sí. curl y xh envían solicitudes, jq las lee, ngrok y mkcert manejan el acceso local, watchexec cierra el ciclo de edición-ejecución, y Docker te proporciona infraestructura desechable. Ninguna de ellas pide mucho antes de ser útil.

apidog-cli es la pieza que enlaza el ciclo con tu proyecto API real, para que los endpoints y las pruebas que ejecutas desde la terminal sean los mismos que tu equipo diseña y distribuye. Descarga Apidog para configurar un proyecto, luego contrólalo desde la línea de comandos con el CLI en tu pipeline de CI. La misma idea de velocidad y huella, aplicada a todo el ciclo de vida de la API en lugar de una solicitud a la vez.