Conocé la nueva alternativa HTTP para Python
Zapros es un nuevo cliente HTTP para Python que separa la lógica del protocolo (cookies, redirects, headers) de la del transporte (TCP, TLS, DNS). Su creador trabajó como mantenedor de HTTPX en el equipo encode y decidió construir una alternativa porque HTTPX mezclaba ambas capas, generando confusión sobre dónde estaba el cuello de botella real. OpenAI y Anthropic ya adoptaron un adapter basado en este enfoque en producción.
En 30 segundos
- Zapros es un cliente HTTP async-only que nació como proyecto educativo en 2022, pero ganó tracción después de que su autor se convirtiera en mantenedor de HTTPX.
- El problema que intenta resolver es la mezcla de concerns en clientes HTTP tradicionales: comportamiento RFC (cookies, redirects) acoplado al transporte (TCP, TLS, HTTP/2).
- Separa explícitamente la capa de protocolo de la de transporte, permitiendo cambiar backends sin afectar la API HTTP.
- OpenAI y Anthropic Python SDKs adoptaron un adapter basado en este concepto en producción, validando el enfoque.
- Es un proyecto más educativo que feature-completo, pero demuestra que el diseño importa más que la cantidad de features.
Qué es Zapros
Zapros es un cliente HTTP para Python construido con arquitectura modular, donde la capa de protocolo HTTP está completamente separada de la capa de transporte. Esto significa que vos podés intercambiar el backend de transporte (TCP, TLS, DNS) sin tocar la lógica HTTP.
El viaje del autor: de usuario a mantenedor de HTTPX
En 2022, el creador de Zapros construyó un pequeño cliente HTTP experimental llamado Zapros como proyecto educativo. Era async-only, sin dependencias externas, y más que nada un ejercicio de aprendizaje. La cosa no terminó ahí: pocos meses después, se unió al equipo encode (los que mantienen HTTPX) y se convirtió en mantenedor del proyecto.
Durante esos años ganó experiencia real. Construyó herramientas sobre HTTPX, como una capa de caching que tuvo adopción en el mundo real (spoiler: eso le enseñó que los clientes HTTP necesitaban más flexibilidad). También vio cómo httpcore, el motor que impulsa HTTPX, tenía issues sin resolver que afectaban directamente a los usuarios.
Sobre 2024-2025, el desarrollo de HTTPX se ralentizó significativamente. Reviews lentos, releases infrequentes, y ese feeling de abandono que generan los proyectos que antes se movían rápido. Fue ahí cuando empezó a alejarse. Relacionado: ejecutar agentes sin dependencias externas.
El problema: mezcla de concerns en clientes HTTP tradicionales
Acá viene lo importante: ponele que reportás un bug en HTTPX donde dice “el cliente es lento” o “la pooling de conexiones no funciona bien”. Nadie sabe si el problema está en la lógica HTTP (cookies, redirects, headers, caching) o en la de transporte (TCP, TLS, DNS, HTTP/1.1 vs HTTP/2). Los dos están mezclados en la misma clase.
Es como armar un auto donde el motor y la transmisión están pegados: si algo se rompe, ¿cuál fue? ¿El motor es lento, o la transmisión no transfiere bien la potencia, o ambos? No hay forma de saberlo porque no podes aislar variables. HTTPX tiene exactamente este problema (igual que Requests, aiohttp y casi todos los clientes HTTP que existen).
Las preguntas que genera esta mezcla son:
“¿Este cliente soporta HTTP/2?” (pregunta de transporte)
“¿Tiene caching de DNS?” (también transporte)
“¿Puedo cambiar el backend TLS?” (transporte, pero acoplado al cliente)
O afirmaciones como:
“Este cliente HTTP es lento” (¿protocolo o transporte?)
“La pooling de conexiones es mala” (claramente transporte, pero no podes cambiarla sin reescribir todo)
O la de nadie:
“¿Puedo usar un transporte diferente manteniendo la misma API HTTP?” Nadie se hace esa pregunta porque no es posible.
Cómo Zapros lo resuelve: separación de capas
Zapros se construyó alrededor de una premisa arquitectónica muy clara: la capa HTTP debe implementar solo el protocolo (RFC compliance), y la capa de transporte debe estar totalmente aislada, responsable únicamente de enviar y recibir bytes. Tema relacionado: cómo proteger tus APIs.
Esto significa que la capa HTTP no sabe nada de TCP, TLS o HTTP/2. La capa de transporte no toca cookies ni redirects. Son dos piezas que hablan por una interfaz bien definida, y podés cambiar una sin afectar la otra (eso sí, tenés que cambiarlas con propósito, no al boleo).
El resultado: si reportás que Zapros es lento, sabemos exactamente qué investigar. Si dicen “necesito un backend de TLS diferente”, vos cambias el transporte sin tocar el protocolo. Si preguntás “¿soporta HTTP/2?”, la respuesta es clara: depende del transporte que uses.
Validación en producción: OpenAI y Anthropic lo adoptaron
El autor construyó un adapter que reemplazaba httpcore (el transporte de HTTPX) con aiohttp, manteniendo la API HTTP de HTTPX sin cambios. Los SDKs de Python de OpenAI y Anthropic lo adoptaron en producción.
¿Por qué? Porque les permitía mantener la API estable mientras usaban un transporte más robusto. Esto no hubiera sido posible en una arquitectura donde protocolo y transporte estuvieran acoplados (y es exactamente lo que Zapros previene desde el diseño).
Comparativa técnica: Zapros vs alternativas
| Cliente | Async | Zero-deps | HTTP/2 | Pooling | Arquitectura | Mantenimiento |
|---|---|---|---|---|---|---|
| Zapros | Solo async | Sí | Configurable en transporte | Delegado al transporte | Separación explícita | Educativo / experimental |
| HTTPX | Sí | No (httpcore, certifi) | Sí, en httpcore | Incluido, no intercambiable | Acoplado | Lento (2024-2025) |
| aiohttp | Solo async | No (yarl, multidict, frozenlist) | Sí | Incluido, configurable | Acoplado | Activo |
| Requests | No (sync) | No (urllib3, chardet, etc) | No | Incluido, no intercambiable | Acoplado | Mantenimiento mínimo |
Errores comunes al evaluar un cliente HTTP
Error 1: Asumir que “rápido” = mejor cliente
Ves un benchmark donde Zapros es más rápido que HTTPX y pensás “genial, cambio todo”. Problema: no sabés si es más rápido porque el protocolo es más eficiente o porque el transporte está optimizado para ese test específico. Sin arquitectura clara, es como comparar autos por aceleración en línea recta sin mirar el consumo, agarre o fiabilidad. Para más detalles técnicos, mirá herramientas modernas para desarrollo.
Error 2: Pensar que “zero-dependencies” siempre es mejor
Zapros es zero-dep, pero eso no significa que sea mejor para todo. Si necesitás HTTP/2 con soporte real de ALPN, pooling inteligente y TLS moderno, eventualmente vas a depender de algo externo para el transporte. Zero-deps es un tradeoff: simplicidad ahora vs. capacidades limitadas después.
Error 3: Mezclar “educativo” con “listo para producción”
El mismo autor de Zapros es claro: es más un proyecto educativo que feature-completo. Migrar toda tu base de código a algo educativo porque la arquitectura te parece elegante es como usar un prototipo de auto porque la teoría del motor es más clara que la de la competencia. La elegancia arquitectónica importa, pero la estabilidad también.
Cuándo usar Zapros vs. otras alternativas
Usá Zapros si: Estás haciendo un proyecto nuevo, quieres entender cómo funciona la arquitectura de clientes HTTP, necesitás flexibilidad en el backend de transporte, o estás construyendo algo donde la separación de concerns es crítica (por ejemplo, un cliente HTTP que pueda soportar múltiples transports).
Seguí con HTTPX si: Necesitás estabilidad comprobada, features amplias (soporte completo de HTTP/2, conexiones persistentes, etc.), o tu proyecto ya está corriendo bien con HTTPX y no hay razón para cambiar. Ojo: si HTTPX te está dando problemas de velocidad o conectividad, el problema es probablemente en httpcore (el transporte), y ahí el adapter con aiohttp puede ser más práctico que migrar completamente.
Considerá aiohttp si: Necesitás async-only, quieres un proyecto activamente mantenido, y no te molesta tener más dependencias. aiohttp tiene features sólidas y una comunidad activa. Sobre eso hablamos en elegir la plataforma correcta.
Preguntas Frecuentes
¿Cuáles son los problemas principales de HTTPX?
El desarrollo se ralentizó significativamente desde 2024. Las reviews son lentas, los releases infrequentes, y httpcore (su motor) tiene issues sin resolver que afectan directamente a usuarios. Además, la arquitectura mezcla protocolo y transporte, haciendo difícil aislar problemas de rendimiento o cambiar backends.
¿Qué diferencia tiene Zapros respecto a otros clientes HTTP?
La separación explícita entre protocolo HTTP y transporte de red. En otros clientes (HTTPX, aiohttp, Requests), ambas capas están acopladas. En Zapros, podes cambiar el transporte sin afectar la lógica HTTP, lo que clarifica dónde están los cuellos de botella y qué capacidades pueden agregarse.
¿Vale la pena migrar a Zapros desde HTTPX?
Probablemente no, a menos que HTTPX esté generándote problemas específicos que no podes resolver. Zapros es educativo y experimental. Lo que tiene valor de Zapros es el concepto arquitectónico, que ya está validado por el adapter que adoptaron OpenAI y Anthropic (sin requerir que migren a Zapros completamente).
¿Por qué mezclar capas HTTP es un problema de diseño?
Porque vuelve imposible aislar el origen de los problemas. Si reportás “lento” o “bad pooling”, no sabés si arreglarlo en el protocolo o en el transporte. El diseño acoplado hace que cualquier cambio en una capa requiera reescribir todo. La separación permite evolucionar cada parte independientemente.
¿Qué validó que el enfoque de Zapros funciona?
Que OpenAI y Anthropic adoptaron en producción un adapter que reemplazaba httpcore por aiohttp manteniendo la API de HTTPX. Esto demuestra que poder intercambiar el transporte sin cambiar el protocolo es una capacidad valiosa y viablemente útil en mundo real.
Conclusión
Zapros no es una alternativa lista para producción a HTTPX, y su creador es honesto sobre eso. Lo que importa es que demuestra que la arquitectura de un cliente HTTP importa más de lo que se reconoce en el ecosistema Python. La mezcla de protocolo y transporte es la razón por la que cuesta tanto entender dónde están los cuellos de botella reales, y por qué cambiar backends es complicado.
Si HTTPX te funciona, está bien mantenerlo. Si tenés problemas específicos de transporte (connectionpooling, TLS, HTTP/2), investigá el adapter con aiohttp antes de migrar completamente. Y si estás diseñando un cliente HTTP nuevo o enseñando arquitectura de redes, Zapros es un excelente ejemplo de cómo pensar en capas y separación de concerns.
