Política de caché HTTP para webs y APIs de empresa
Define qué respuestas web y de API pueden almacenarse, durante cuánto tiempo, cuándo revalidarlas y cómo impedir que una caché compartida mezcle datos.
La caché es una decisión sobre datos, no solo rendimiento
Una caché HTTP puede reducir latencia y tráfico al reutilizar respuestas, pero una política incorrecta puede servir contenido desactualizado o exponer una respuesta personalizada a otra sesión. La política debe partir de quién puede ver el recurso, con qué frecuencia cambia y qué impacto tendría reutilizarlo.
El estándar RFC 9111 define el almacenamiento y la reutilización de respuestas en cachés privadas y compartidas. En particular, una caché compartida debe tratar con cuidado las respuestas asociadas a Authorization; no asumas que cualquier respuesta autenticada es segura para guardar en una CDN.
Matriz de decisión inicial
| Tipo de respuesta | Enfoque que se debe evaluar | Revisión necesaria |
|---|---|---|
| Recursos estáticos versionados | Caché pública con vida larga si la URL cambia al cambiar el contenido | Confirmar invalidación y estrategia de nombres |
| Catálogo público que cambia con frecuencia | Vida corta o validadores como ETag y Last-Modified |
Medir frescura frente a peticiones al origen |
| Respuesta específica de una sesión | Caché privada o no almacenamiento, según sensibilidad y contrato | Revisar cookies, cabeceras y CDN compartida |
| Datos sensibles o transacciones | no-store cuando corresponda y controles de acceso de origen |
No confundir directiva de caché con garantía de privacidad |
no-cache permite almacenar una respuesta, pero exige validarla antes de reutilizarla; no-store indica que no debe almacenarse. La validación condicional puede reducir la transferencia: el cliente conserva un ETag y solicita una comprobación posterior, por ejemplo mediante If-None-Match.
Diseño por capas
- Inventaría rutas y respuestas: público, autenticado, por usuario, por organización y de operación.
- Decide si la caché es navegador, proxy o CDN; no uses una sola regla para todos los saltos.
- Define
Cache-Control, validadores y, si el contenido varía por cabecera,Varycoherente con la clave real. - Para respuestas personalizadas, comprueba el comportamiento con dos usuarios y dos organizaciones distintas.
- Prueba actualización, invalidación, sesión cerrada, error del origen y respuesta antigua.
- Revisa cabeceras observadas desde el cliente y desde la capa compartida; la configuración declarada no demuestra por sí sola qué se está sirviendo.
No añadas public para “hacer más rápida” una ruta sin demostrar que todos los usuarios pueden recibir exactamente la misma representación. Define un propietario de política y un mecanismo de reversión, igual que en el presupuesto de rendimiento web. Para una API pública, documenta también la semántica en el contrato OpenAPI.