La mayoría de los flujos de trabajo de los desarrolladores aún se ejecutan a través de la terminal, y las herramientas que perduran con el tiempo tienden a compartir una característica: son de código abierto. Puedes leer el código, autoalojar cualquier cosa que ejecute un servidor y nunca encontrar una licencia de asiento o una barrera de "contactar ventas". Cuando una herramienta tiene licencia MIT o Apache y reside en GitHub, también obtienes una señal de mantenimiento que puedes verificar tú mismo, además de la libertad de bifurcarla si el proyecto se estanca.
Esta publicación es una lista curada de herramientas CLI gratuitas y genuinamente de código abierto que se ganan un lugar en el trabajo diario de desarrollo de API y backend. Cada herramienta aquí se distribuye bajo una licencia permisiva o copyleft, mantiene su código fuente en GitHub y no cuesta nada ejecutarla. El enfoque está en la licencia y el bloqueo, no en el tamaño bruto o la velocidad de inicio.
Obtendrás siete herramientas para el ciclo principal: realizar solicitudes, analizar JSON, probar flujos HTTP, trabajar con GitHub y exponer un servidor local a internet. Cada entrada nombra la licencia, enlaza el repositorio y muestra un comando real para que puedas verlo en funcionamiento. También hay una nota honesta sobre dónde encaja una herramienta comercial de nivel gratuito, claramente etiquetada para que nunca la confundas con una entrada de código abierto.
¿Qué hace que una herramienta CLI sea “de código abierto” para el desarrollo?
Muchas herramientas son gratuitas para descargar pero cerradas en su interior, o de código abierto en el núcleo con las partes útiles detrás de un muro de pago. Para esta lista, una herramienta califica según tres criterios:
- Licencia. Se distribuye bajo una licencia aprobada por la OSI: MIT, Apache 2.0, BSD o GPL. Eso es lo que te permite usarla comercialmente, autoalojarla y bifurcarla sin preguntar.
- Código fuente en GitHub (o equivalente). Puedes leer cada línea, reportar problemas y juzgar el mantenimiento a partir del historial de commits y la cadencia de lanzamientos.
- Sin dependencia. Sin cuenta obligatoria, sin telemetría que no puedas desactivar, sin componente de servidor que te veas obligado a alquilar. Si ejecuta un servicio, puedes ejecutar ese servicio tú mismo.
Las estrellas y los commits recientes también importan, pero son secundarios. Una herramienta MIT tranquila y estable supera a una de moda con una licencia de código disponible que restringe el uso comercial. Revisa el archivo LICENSE antes de estandarizar cualquier cosa.
curl: el cliente HTTP universal
curl es la herramienta contra la que se miden casi todas las demás herramientas HTTP. Habla docenas de protocolos, se incluye por defecto en casi todos los sistemas operativos y se ha mantenido continuamente desde 1996. Tiene licencia bajo la permisiva licencia curl (un derivado de MIT/X), y el código fuente se encuentra en github.com/curl/curl.
Para el trabajo con API, curl es tu herramienta de solicitud de mínimo común denominador. Ya está instalada, por lo que cualquier script o trabajo de CI puede depender de ella.
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","body":"Filed from curl"}'
Mejor en: portabilidad y scripting. Si ejecuta un shell, ejecuta curl. El límite honesto es la ergonomía. La salida de curl en bruto es densa, el manejo de encabezados es verboso y leer un cuerpo JSON significa redirigirlo a otro lugar. Por eso existen las siguientes dos herramientas.
HTTPie: curl con salida amigable para humanos
HTTPie es un cliente HTTP moderno construido para personas, no solo para scripts. Las solicitudes se leen como inglés simple, JSON es el tipo de cuerpo predeterminado y las respuestas vienen coloreadas y formateadas. Tiene licencia bajo BSD-3-Clause y es de código abierto en github.com/httpie/cli.
Instálalo con pip, luego usa el comando http:
pip install httpie
http POST httpbin.org/post name=apidog role=platform
Esa es la solicitud completa. name=apidog se convierte automáticamente en un campo JSON, los encabezados y el estado se imprimen con color, y el cuerpo se muestra con formato sin necesidad de una segunda herramienta. Mejor en: exploración interactiva y depuración manual. El límite honesto es que es un paquete de Python, por lo que es una instalación más pesada que un único binario estático, y en imágenes de CI ajustadas, es posible que aún recurras a curl.
jq: el procesador JSON que toda pipeline necesita
Las API devuelven JSON, y jq es cómo lo procesas desde la línea de comandos. Filtra, reforma y extrae campos con un pequeño lenguaje de consulta, y se compone limpiamente con curl o HTTPie en una tubería. jq tiene licencia MIT y es mantenido por la comunidad en github.com/jqlang/jq.
Redirige una respuesta de API directamente a ella:
curl -s https://api.github.com/repos/jqlang/jq \
| jq '{name: .name, stars: .stargazers_count, license: .license.spdx_id}'
Eso extrae tres campos de una respuesta grande y construye un objeto limpio. Mejor en: transformar JSON ruidoso en la forma exacta que necesitas para el siguiente paso en un script. El límite honesto es la curva de aprendizaje. La sintaxis de jq es potente pero concisa, y las transformaciones complejas pueden volverse crípticas rápidamente. Sin embargo, para la extracción de campos cotidiana, aprenderás el 90% de lo que necesitas en una tarde.
gh: la CLI de GitHub
gh trae GitHub a tu terminal: pull requests, issues, lanzamientos, ejecuciones de Actions y llamadas a la API, todo sin abrir un navegador. Está escrito en Go, tiene licencia MIT y reside en github.com/cli/cli. Dado que gran parte del trabajo de API y backend se encuentra en repositorios de GitHub, pertenece al kit principal.
Un truco útil: gh api te proporciona un wrapper autenticado y paginado sobre las API REST y GraphQL de GitHub, para que no tengas que introducir tokens manualmente en curl.
gh api repos/cli/cli/releases --jq '.[0].tag_name'
Eso imprime la última etiqueta de lanzamiento usando el filtro jq incorporado de gh. Mejor en: scripting de GitHub, desde flujos de trabajo de CI hasta automatización de lanzamientos. El límite honesto es el alcance; está diseñado solo para GitHub. Para GitLab o Gitea, querrás sus respectivas CLI o curl simple contra sus API.
Hurl: pruebas HTTP de texto plano que puedes commitear
Hurl ejecuta y prueba solicitudes HTTP definidas en un archivo de texto plano simple. Escribes solicitudes, afirmas sobre códigos de estado, encabezados y cuerpos JSON, y encadenas llamadas capturando valores de una respuesta a la siguiente. Convierte "probar la API" en un archivo que puedes registrar en git. Hurl está escrito en Rust, tiene licencia Apache 2.0 y es mantenido por Orange en github.com/Orange-OpenSource/hurl.
Escribe un archivo .hurl:
GET https://api.github.com/repos/Orange-OpenSource/hurl
HTTP 200
[Asserts]
jsonpath "$.name" == "hurl"
jsonpath "$.stargazers_count" > 1000
Luego ejecútalo:
hurl --test repo.hurl
Hurl sale con 0 cuando todas las aserciones pasan y con un valor distinto de cero cuando una falla, lo que lo hace ideal para CI. Mejor en: pruebas de integración legibles y versionadas que todo un equipo puede editar sin aprender un framework. El límite honesto es que se enfoca en las pruebas de solicitud/respuesta HTTP; no es una herramienta completa de pruebas de contratos o de carga. Para una visión más amplia de cómo las pruebas CLI encajan en un flujo de trabajo de desarrollo de API primero en especificación, el archivo de aserciones combina bien con una fuente de verdad de OpenAPI.
cloudflared: expón un servidor local sin un túnel de pago
A veces necesitas una URL pública para la API que se ejecuta en tu portátil: un callback de webhook, una demostración, una prueba móvil contra un host real. cloudflared es el cliente de túnel de Cloudflare, y su modo de túnel rápido te proporciona una URL pública temporal *.trycloudflare.com con un solo comando y sin cuenta. Está escrito en Go, tiene licencia Apache 2.0 y es de código abierto en github.com/cloudflare/cloudflared.
Apúntalo a tu puerto local:
cloudflared tunnel --url http://localhost:3000
Imprime una URL HTTPS pública que redirige a localhost:3000 hasta que lo detengas. Mejor en: túneles rápidos, gratuitos y ad-hoc cuando no quieres registrarte en nada. Si prefieres permanecer completamente en el ecosistema npm, localtunnel (MIT) hace el mismo trabajo con npx localtunnel --port 3000. El límite honesto de los túneles rápidos: la URL es aleatoria y efímera, y para túneles con nombre estables, crearás una cuenta y una configuración de Cloudflare, aunque el cliente sigue siendo de código abierto de cualquier manera.
git: control de versiones como CLI, no como GUI
Es fácil olvidar que git es una herramienta de línea de comandos antes que nada. Cada especificación de API, archivo de prueba y escenario de Hurl mencionado anteriormente pertenece a un repositorio git, y la CLI es donde reside el poder real: staging preciso, bisect, rebase y ganchos que ejecutan tus pruebas de API antes de que un commit se aplique. git tiene licencia GPLv2 y se desarrolla de forma abierta en github.com/git/git.
Un pequeño ejemplo que une el kit: un hook de pre-commit que ejecuta tus pruebas de Hurl antes de que el código se registre.
echo 'hurl --test *.hurl' > .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
Mejor en: ser el sustrato sobre el que se asienta todo lo demás. Autoalojado desde el primer día, sin servidor requerido y forjable en todos los sentidos. El límite honesto es que git es control de versiones, no alojamiento de proyectos; la capa de alojamiento (GitHub, GitLab, Gitea) es una elección separada, y solo algunas de ellas son de código abierto.
Un aparte honesto: dónde encaja Apidog
Apidog no es de código abierto, por lo que no pertenece a esta lista como una entrada OSS. Es un producto comercial con un nivel gratuito, y vale la pena mencionarlo aquí por una razón: las herramientas anteriores son excelentes individualmente, pero terminas uniéndolas manualmente. curl para solicitudes, jq para analizar, Hurl para pruebas, un servidor mock separado, un generador de documentación, variables de entorno gestionadas en perfiles de shell.
Apidog integra diseño, pruebas, mocking y documentación en un solo espacio de trabajo, y apidog-cli lo lleva a la terminal. Es un paquete npm (npm install -g apidog-cli), y ejecuta escenarios de prueba, gestiona endpoints y esquemas, activa expectativas de mock, e importa o exporta OpenAPI, todo con salida JSON estructurada que los scripts y agentes de IA pueden leer. apidog run sale con 0 si todo pasa y con un valor distinto de cero si falla, por lo que se integra en CI de la misma manera que Hurl.
El planteamiento honesto: si quieres cero dependencia y acceso completo al código fuente, el kit de código abierto es la elección correcta, y de eso trata este artículo. Si prefieres no unir siete herramientas y mantener la infraestructura tú mismo, el nivel gratuito de Apidog más su CLI te ofrece una alternativa integrada. Ambos son válidos; optimizan para cosas diferentes. Si sigues la ruta de la CLI, la guía de instalación te guiará a través de la autenticación y los primeros comandos.
Cómo elegir
Adapta la herramienta al trabajo. La mayoría de los desarrolladores ejecutan varias de estas juntas: curl o HTTPie para obtener datos, jq para analizar, Hurl para probar, git para versionar todo.
| Herramienta | Mejor para | Instalación | ¿Código abierto? | Notas |
|---|---|---|---|---|
| curl | Solicitudes portátiles, scripting | Preinstalado | Sí (curl/estilo MIT) | Ya en todos los sistemas |
| HTTPie | Depuración amigable para humanos | pip install httpie |
Sí (BSD-3-Clause) | Coloreado, JSON por defecto |
| jq | Análisis de respuestas JSON | gestor de paquetes / binario | Sí (MIT) | El pegamento de la pipeline |
| gh | Scripting de GitHub | gestor de paquetes / binario | Sí (MIT) | Solo para GitHub por diseño |
| Hurl | Pruebas HTTP commiteables | Binario único | Sí (Apache 2.0) | Sale con un valor distinto de cero si falla |
| cloudflared | Túneles públicos gratuitos | Binario único | Sí (Apache 2.0) | Los túneles rápidos no necesitan cuenta |
| git | Control de versiones | Preinstalado | Sí (GPLv2) | Sustrato para el resto |
| apidog-cli | Flujo de trabajo de API integrado | npm i -g apidog-cli |
No (nivel gratuito) | Diseño + prueba + mock + documentación |
La regla general: opta por la herramienta de código abierto de propósito único cuando quieras poseer la infraestructura, y opta por una plataforma integrada cuando prefieras no hacerlo. Si estás evaluando esa compensación en una cadena de herramientas completa, el desglose de Apidog como plataforma integral de desarrollo de API cubre lo que reemplaza la ruta integrada.
Conclusión
El código abierto se gana su lugar en la terminal por ser inspeccionable, autoalojable y libre de dependencia. curl, HTTPie, jq, gh, Hurl, cloudflared y git cubren el núcleo del desarrollo de API y backend, y cada uno de ellos es una licencia que puedes leer y un repositorio que puedes bifurcar. Comienza con las dos o tres que se ajusten a tu ciclo actual y añade el resto según las necesites.
Si estás construyendo flujos de trabajo basados en agentes sobre estas herramientas, se aplican los mismos principios de terminal-first, y la salida JSON estructurada se convierte en el tejido conectivo; el artículo sobre asistentes de codificación de IA para el desarrollo de API profundiza más en ello. Y si mantener siete herramientas separadas comienza a parecer un trabajo en sí mismo, Descarga Apidog y prueba la CLI de Apidog para ver cómo es el camino integrado antes de comprometerte.