🔴 "no-cache" не означает «не кэшировать»: 4 директивы заголовка Cache-Control, которые важно различать 🔴

Посмотрите на заголовок (header):

Cache-Control: no-cache

Кажется, что ответ нельзя сохранить в кэше.
Но на самом деле no-cache означает другое.



Разбираемся подробно, чем отличаются основные директивы Cache-Control 👇


1️⃣ no-cache
Сохранить можно, использовать без проверки нельзя.

Cache-Control: no-cache
ETag: "product-v7"

Клиент может сохранить ответ.
Но при следующем обращении он должен спросить у сервера «Версия product-v7 всё ещё актуальна?»

Если данные не изменились, сервер вернёт:

304 Not Modified

И клиент использует сохранённый ответ.


2️⃣ no-store
Сохранять нельзя вообще.

Cache-Control: no-store

Запрос и ответ не должны сохраняться в HTTP-кэше.

Обычно используется для чувствительных данных:
▫️ токенов
▫️ одноразовых кодов
▫️ платёжной информации
▫️ результатов аутентификации


3️⃣ private
Хранить можно только в персональном кэше.

Cache-Control: private, max-age=60

Ответ может сохранить браузер конкретного пользователя.

Но общий кэш — например, CDN или Proxy — не должен сохранять его для других клиентов.

Подходит для персонализированных данных:

GET /profile
GET /orders
GET /recommendations

4️⃣ public
Ответ можно хранить в общем кэше

Cache-Control: public, max-age=300

Ответ могут сохранять не только браузеры, но и общие кэши:
▫️ CDN
▫️ Reverse Proxy
▫️ API Gateway

Подходит для публичных данных:
▫️ справочников
▫️ статей
▫️ общего каталога
▫️ публичной конфигурации



Что должен определить системный аналитик при разработке требований к кэшу, чтобы Cache-Control помогал, а не вредил системе:
:
✅ можно ли вообще сохранять ответ
✅ допустим ли кэш только на устройстве пользователя
✅ можно ли использовать общий кэш
✅ нужна ли проверка актуальности перед использованием
✅ содержит ли ответ персональные или чувствительные данные


Cache-Control определяет не только скорость работы API.
От него зависят актуальность и безопасность данных 👌

#RestApiGA