ETag: qué es y cómo ahorra datos en HTTP

ETag significa entity tag y es un identificador que el servidor devuelve para una representación concreta de un recurso HTTP. Puede basarse en un hash del contenido, una revisión o una marca interna. Su formato no obliga a usar un algoritmo determinado, pero debe permitir comparar versiones de una misma URL.

También puede servirte: WebTransport: qué es y cuándo conviene

Cuando el cliente recibe un ETag, puede guardarlo junto con la respuesta. La próxima vez que necesite comprobar si el recurso cambió, no tiene que descargarlo completo de entrada: envía el valor en el encabezado If-None-Match y pide al servidor una comparación.

El validador describe una representación, no garantiza que el contenido sea correcto ni reemplaza Cache-Control. La política de caché decide cuándo reutilizar una respuesta; ETag permite validar si la copia almacenada todavía coincide con la versión elegida por el servidor.

En una solicitud condicional GET, el cliente envía If-None-Match con uno o más ETags conocidos. Si el servidor encuentra una coincidencia para la representación seleccionada, responde 304 Not Modified y omite el cuerpo. El cliente conserva la respuesta que ya tiene y ahorra transferencia.

Si no hay coincidencia, el servidor devuelve una respuesta normal con el contenido actual y su nuevo ETag. El cliente reemplaza su copia y vuelve a guardar el validador. La secuencia permite actualizar recursos sin inventar una descarga cero: todavía hay una consulta, pero no se repite el cuerpo cuando nada cambió.

If-None-Match también puede proteger operaciones inseguras con el valor *. En ese caso, la condición ayuda a evitar que una creación sobrescriba una representación que ya existe. Para actualizaciones colaborativas, If-Match y una respuesta 412 pueden detectar que otra persona editó el recurso antes de guardar.

Un ETag fuerte representa una comparación exacta de bytes: es útil cuando importa que dos respuestas sean idénticas, incluso para solicitudes de rango. Un ETag débil lleva el prefijo W/ y expresa equivalencia semántica; puede servir para validar una caché aunque cambien detalles que no alteran el significado.

El servidor debe generar un nuevo valor cuando cambia la representación que está entregando. Cambiar el ETag por cada respuesta sin relación con el contenido elimina la ventaja del validador, mientras que conservarlo después de un cambio puede hacer que el cliente use datos viejos.

ETag y Last-Modified pueden coexistir. If-None-Match suele ser más preciso para comparar representaciones, mientras que Last-Modified ofrece una fecha útil como respaldo. La elección debe contemplar compresión, transformaciones de intermediarios y si el cliente necesita rangos de bytes.

Definí qué representación identifica el ETag: HTML, JSON, imagen o descarga. Generá el valor desde el contenido o desde una versión que cambie al publicar y enviá también una política Cache-Control coherente. Probá una primera respuesta 200, una solicitud con If-None-Match coincidente y otra con un valor obsoleto.

Registrá que 304 no trae cuerpo y que el cliente debe reutilizar su respuesta almacenada. En una API, mantené el mismo contrato de validación para GET y documentá qué pasa cuando el recurso cambia. Para escrituras, elegí If-Match si necesitás evitar que una edición pise otra y tratá 412 como un conflicto que debe resolverse.

Medí bytes transferidos, porcentaje de respuestas 304, latencia y errores de validación. Revisá también proxies y CDN: una transformación que cambia la representación puede requerir otro validador. Un ETag útil reduce tráfico y detecta actualizaciones; no corrige por sí solo una estrategia de caché mal definida.