Gzip

Comprima un payload con gzip, deflate o brotli, o descomprímalo de vuelta a sus bytes originales, mediante un solo endpoint que se encarga del trabajo pesado que su aplicación no debería hacer en un hilo de solicitud.

La compresión está en todas partes, pero rara vez bajo su control

La mayoría de los stacks web comprimen las respuestas HTTP de forma transparente, lo cual funciona bien para servir páginas pero es inútil cuando necesita comprimir un archivo de log antes de archivarlo, reducir una exportación JSON antes de guardarla, o descomprimir un webhook entrante que llegó codificado en gzip desde un tercero. Esas son tareas a nivel de archivo o blob, no de respuesta HTTP, y hacerlas en línea dentro del código de su aplicación significa quemar ciclos de CPU que podrían estar atendiendo usuarios.

Tres algoritmos, tres compromisos distintos

POST /data/gzip recibe un parámetro de algoritmo — gzip, deflate o brotli — más una dirección de compress o decompress, y devuelve el resultado mediante un task_id. Gzip es la opción más universal, legible por prácticamente cualquier herramienta desde los años noventa; deflate es su algoritmo central sin el envoltorio de gzip, útil cuando una especificación lo exige explícitamente (como algunas estructuras internas de ZIP o implementaciones HTTP más antiguas); brotli, desarrollado y liberado como código abierto más recientemente, suele comprimir más que gzip a una velocidad comparable, lo cual importa cuando está optimizando costos de almacenamiento o tamaño de transferencia para payloads de texto grandes.

Qué determina el tamaño final que obtiene

La razón de compresión depende por completo de la naturaleza de sus datos: texto muy repetitivo como logs, exportaciones CSV o JSON minificado puede reducirse de forma drástica, mientras que formatos ya comprimidos como JPEG o un archivo previamente comprimido con gzip apenas cambiarán de tamaño, e incluso pueden crecer un poco por el overhead del formato. El endpoint no intenta adivinar qué es óptimo para su contenido: usted elige el algoritmo, y el resultado le dice exactamente qué razón de compresión obtuvo.

Diseñado para flujos de trabajo, no para descargas puntuales

Una tarea fallida — entrada malformada, un flujo ilegible — no le cuesta nada, porque solo cobramos las tareas que terminan con éxito después de agotar los reintentos. Como cada llamada es asíncrona y devuelve un task_id, puede lanzar tareas de compresión desde un worker de cola, una exportación programada o un manejador de webhooks sin bloquear la respuesta, y luego recoger el archivo comprimido o descomprimido desde un enlace firmado o su propio receptor de webhooks.

Dónde encaja dentro de un proceso más grande

Trátelo como un bloque utilitario que inserta en cualquier flujo que mueva datos entre sistemas con expectativas de compresión distintas, no como un destino en sí mismo. Este endpoint combina de forma natural con nuestras herramientas de comprimidos y conversión: descomprima un payload gzip entrante, entregue los bytes crudos a un conversor de formato y luego vuelva a comprimir la salida con brotli antes de guardarla.