Si alguna vez has necesitado probar un cliente HTTP sin levantar un backend real, probablemente has utilizado httpbin. Es un pequeño servicio web que devuelve tu solicitud, para que puedas ver exactamente lo que tu código envió. Esto lo hace perfecto para depurar encabezados, comprobar cómo tu cliente maneja un error 500 o confirmar que tu token de autenticación realmente llegó a la solicitud. Puedes apuntar cualquier herramienta a él, desde un comando curl en bruto hasta un cliente completo como Apidog. El proyecto reside en httpbin.org y es de código abierto bajo una licencia ISC.
¿Qué es httpbin?
httpbin es un servicio de solicitud y respuesta HTTP. Le envías una solicitud; te devuelve una descripción JSON de esa solicitud. Nada más. Fue creado por Kenneth Reitz, el desarrollador detrás de la popular biblioteca Python requests, y está escrito en Python con Flask.
Su valor reside en su simplicidad. Digamos que quieres saber si tu cliente HTTP establece correctamente un encabezado User-Agent. Accedes a https://httpbin.org/headers y la respuesta lista cada encabezado que el servidor recibió. Sin base de datos, sin inicio de sesión, sin configuración. Obtienes un espejo limpio de tu propia solicitud.
httpbin.org es la instancia pública y es conveniente para comprobaciones rápidas. También puede ser lento o estar temporalmente no disponible, ya que es un servicio compartido gratuito. El mantenimiento ha cambiado a lo largo de los años; el código ahora reside en el repositorio de GitHub postmanlabs/httpbin, con forks comunitarios como el de Kong también circulando. Para cualquier cosa que ejecutes a menudo, el autoalojamiento es la opción más segura. Más sobre eso a continuación.
Puntos finales clave de httpbin
httpbin expone un conjunto de puntos finales, cada uno destinado a un tipo de prueba. Aquí están los que más utilizarás.
| Punto final | Lo que hace |
|---|---|
/get |
Devuelve los argumentos de consulta, encabezados e IP de origen de una solicitud GET |
/post |
Devuelve los datos del formulario, el cuerpo JSON y los encabezados que POSTeas |
/put, /patch, /delete |
La misma idea para otros métodos HTTP |
/status/{codes} |
Devuelve el código de estado que solicites, como /status/404 o /status/503 |
/headers |
Devuelve solo los encabezados de la solicitud que vio el servidor |
/ip |
Devuelve tu dirección IP de origen |
/user-agent |
Devuelve la cadena User-Agent que envió tu cliente |
/delay/{n} |
Espera n segundos antes de responder (hasta 10), para pruebas de tiempo de espera |
/basic-auth/{user}/{passwd} |
Devuelve 200 solo si envías credenciales de autenticación básica coincidentes |
/bearer |
Verifica la existencia de un token Bearer en el encabezado Authorization |
/redirect/{n} |
Te envía a través de n redirecciones, para probar el manejo de redirecciones |
/cookies |
Devuelve las cookies que envió tu cliente |
/uuid |
Devuelve un UUID aleatorio |
/anything |
Devuelve todo sobre la solicitud, sea cual sea el método que uses |
Los puntos finales /status/{codes} y /delay/{n} son los héroes silenciosos aquí. Te permiten forzar rutas de error y respuestas lentas bajo demanda, lo cual es difícil de activar contra una API real. Si quieres generar cuerpos de respuesta falsos en lugar de ecos, combina httpbin con una API falsa para datos de prueba.
Cómo usar httpbin para probar un cliente
La forma más rápida de probar httpbin es con curl. Envía una solicitud GET con un parámetro de consulta:
curl "https://httpbin.org/get?tool=apidog&check=headers"
Obtendrás un objeto JSON que muestra los args, los headers que recibió el servidor y tu IP de origin. Esto confirma que tu cliente envió lo que esperabas.
Para probar cómo tu código maneja un cuerpo POST, envía algo de JSON:
curl -X POST "https://httpbin.org/post" \
-H "Content-Type: application/json" \
-d '{"name": "widget", "qty": 3}'
httpbin devuelve el json parseado, los data en bruto y los encabezados, para que puedas verificar que tu Content-Type y tu carga útil llegaron intactos.
Ahora fuerza un error para probar tu lógica de reintento:
curl -i "https://httpbin.org/status/503"
Obtendrás una respuesta real 503 Service Unavailable. Apunta el manejo de errores de tu cliente a esto y confirma que reintenta o falla de manera elegante. Sustituye por /delay/5 para simular un punto final lento y verifica tu configuración de tiempo de espera.
No tienes que quedarte en la terminal. Cualquier cliente REST puede acceder a estas mismas URL. Si prefieres un flujo de trabajo gráfico, pega https://httpbin.org/get en Apidog, envía la solicitud e inspecciona la respuesta con resaltado de sintaxis, historial guardado y variables de entorno. Esto es útil cuando quieres comparar respuestas entre entornos o compartir una prueba con un compañero de equipo. Para una configuración orientada a la terminal, consulta estos clientes TUI REST API.
Autoalojamiento de httpbin con Docker
La instancia pública de httpbin.org está bien para comprobaciones puntuales, pero puede estar limitada por la tasa de solicitudes o caída cuando la necesitas. Ejecutar tu propia copia soluciona eso y mantiene tu tráfico de prueba privado. La imagen oficial de Docker lo convierte en un trabajo de dos comandos.
Extrae la imagen y ejecútala:
docker pull kennethreitz/httpbin
docker run -p 80:80 kennethreitz/httpbin
El servicio ahora escucha en el puerto 80. Accede a http://localhost/get y obtendrás el mismo comportamiento que el sitio público, sin latencia de red y sin límites de tasa compartidos. Esta es la configuración que deseas en las canalizaciones de CI, donde la fiabilidad importa y no quieres depender de un servicio externo. La imagen está publicada en Docker Hub como kennethreitz/httpbin.
Si el puerto 80 está ocupado en tu máquina, mapea un puerto de host diferente, por ejemplo docker run -p 8080:80 kennethreitz/httpbin, y luego usa http://localhost:8080/get.
Alternativas a httpbin
httpbin hace bien una cosa, pero no es la única opción, y no es una plataforma de prueba completa. Aquí tienes alternativas honestas según lo que necesites.
Postman Echo. Un servicio de eco alojado con el mismo espíritu que httpbin, ejecutado por Postman. Accedes a https://postman-echo.com/get y tu solicitud te es devuelta. Cubre GET, POST, autenticación y puntos finales de utilidad. Consulta la documentación de Postman Echo para ver la lista completa. Si httpbin.org está caído, Echo es un sustituto sólido.
Httpbin autoalojado. Como se muestra arriba, ejecutar la imagen de Docker te da exactamente los mismos puntos finales con control total y sin límites compartidos. Esta es la mejor opción cuando necesitas el comportamiento de httpbin dentro de una red privada o un trabajo de CI.
Servicios de mock. httpbin devuelve tu solicitud; no devuelve datos de dominio realistas. Cuando necesitas respuestas falsas pero estructuradas (una lista de usuarios, un objeto de pedido, resultados paginados), utiliza un servidor mock en su lugar. Apidog tiene mocking inteligente incorporado que genera respuestas realistas a partir de tu esquema, para que tu frontend pueda desarrollarse contra un punto final antes de que exista el backend.
Apidog como cliente y capa de prueba. httpbin es un objetivo al que envías solicitudes. Apidog es la herramienta con la que las envías. Es un cliente API completo y una plataforma de prueba: diseña puntos finales, envía solicitudes, escribe aserciones, encadena solicitudes en escenarios y ejecútalas en CI. Usarías Apidog para acceder a httpbin, o para reemplazarlo una vez que tus necesidades superen un simple eco. Los dos no son equivalentes; httpbin es el pequeño servicio, Apidog es el banco de trabajo a su alrededor. Cuando estés listo para pasar de llamadas curl ad-hoc a pruebas guardadas y repetibles, Apidog te permite importar tus solicitudes existentes y añadir aserciones. Para una visión más amplia de opciones sin instalación, consulta estas herramientas gratuitas de prueba de API en línea.
Preguntas frecuentes
¿Es httpbin de uso gratuito? Sí. La instancia pública de httpbin.org es gratuita y no requiere cuenta. El código fuente es abierto bajo una licencia ISC, por lo que también puedes ejecutarlo tú mismo sin costo.
¿Se sigue manteniendo httpbin? La base de código reside en el repositorio de GitHub postmanlabs/httpbin y recibe algo de atención continua, aunque el mantenimiento ha sido intermitente. Debido a que httpbin.org puede ser inestable, muchos equipos fijan una copia autoalojada de Docker para cualquier cosa importante.
¿Puedo usar httpbin para probar webhooks? En realidad no. httpbin devuelve las solicitudes que le envías, pero no recibirá un evento de un tercero y lo reenviará a tu máquina local. Para eso, usa un servicio de túnel o inspección dedicado; consulta esta guía sobre pruebas de API y webhooks en localhost y esta introducción sobre cómo funcionan los webhooks.
¿Cuál es la diferencia entre httpbin y Postman Echo? Hacen casi lo mismo: devolver tu solicitud HTTP como JSON. httpbin es el servicio original de código abierto en Python y Flask; Postman Echo es un servicio alojado por Postman. Elige el que esté activo y accesible.
¿Puedo probar el manejo de errores con httpbin? Sí. Usa /status/{code} para forzar cualquier código de estado, como /status/500 o /status/429, y /delay/{n} para simular respuestas lentas. Esta es la forma más limpia de ejercitar la lógica de reintento y tiempo de espera de tu cliente.
Conclusión
httpbin es una herramienta pequeña y precisa: apunta un cliente HTTP hacia ella y observa cómo se refleja tu solicitud. Usa /get y /post para confirmar lo que envías, /status y /delay para forzar rutas de error, y la imagen de Docker para ejecutar una copia privada en CI. Cuando necesites más que un eco, busca mocks realistas, suites de prueba guardadas y aserciones.
Ahí es donde una plataforma completa vale la pena. Apidog te ofrece un cliente API para acceder a httpbin, mocking inteligente para reemplazarlo y pruebas automatizadas para asegurar el comportamiento que acabas de verificar. Descarga Apidog y convierte tus rápidas comprobaciones de httpbin en pruebas repetibles.