Las operaciones cuyo contenido cambia poco emiten una cabecera ETag con la firma de la respuesta:
ETag: "a1b2c3d4e5f6..."
Cache-Control: private, max-age=3600Devolver esa firma en la petición siguiente permite que el servidor conteste 304 cuando nada ha cambiado:
GET /v1/public/banks
If-None-Match: "a1b2c3d4e5f6..."Un 304 no lleva cuerpo. Confirma que la copia en poder del cliente sigue vigente, sin transportar el recurso otra vez.
Dónde aplica
Emiten ETag 22 operaciones, de tres clases:
| clase | ejemplo | por qué |
|---|---|---|
| Catálogos | GET /v1/public/banks | Cambian semanalmente y se consultan en cada sesión |
| Sondeo de estado | GET /v1/validations/{id} | Se consultan repetidamente mientras el estado no cambia |
| Paneles de operación | Colas y sus flujos | Refresco continuo sobre datos que a menudo no varían |
Cada una lo declara en su página de referencia. El resto de operaciones no emite ETag, y enviar If-None-Match a ellas no produce error: simplemente se ignora.
Forma de la firma
Los catálogos usan una firma fuerte entre comillas. Las validaciones usan una firma débil que codifica versión y estado —W/"3-processing"—, de modo que cualquier transición cambia el valor. En ambos casos el tratamiento del cliente es el mismo: conservar el valor recibido y devolverlo sin interpretarlo.
Tratamiento en el cliente
- Guardar el
ETagjunto con la respuesta. - Enviarlo como
If-None-Matchen la consulta siguiente del mismo recurso. - Ante un
304, reutilizar la copia guardada; ante un200, sustituirla junto con su nuevoETag.
En el sondeo de una validación asíncrona esta mecánica es la que evita descargar el mismo recurso en cada intento mientras el estado no avanza.