🔴 "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

💸 Высокая ЗП в IT ещё не означает, что у вас останутся деньги 💸

Можно хорошо зарабатывать и всё равно жить от зарплаты до зарплаты.

Моя стратегия другая: сначала создать базу для накоплений, а уже потом тратить оставшееся.

Именно благодаря этому подходу я:
+ купила первую машину из салона в 19 лет,
+ впервые отправила себя учиться в США в 23 года,
+ купила первую квартиру у моря в 24 года и погасила ипотеку на неё за 2 года,
+ объехала почти 20 стран,
+ всё без кредитов, кроме недвижимости.

И всё это работая в найме системным аналитиком.

Сейчас я продолжаю формировать накопления и капитал, придерживаясь привычек, которые со мной с раннего возраста.


Вот 5 принципов, которые всегда со мной 👇


1️⃣ Инвестировать, а не просто хранить деньги

Часть накоплений я направляю в инвестиции.

Не ради быстрого заработка, а чтобы деньги работали в долгосрочной перспективе и не лежали без движения.

Именно эта стратегия помогла мне накопить на первую квартиру.


2️⃣ Постоянно учитывать доходы и расходы

Я веду учёт финансов и заранее устанавливаю лимиты на месяц.

Это не значит запрещать себе всё.

Я покупаю то, что действительно важно и нужно. А для необязательных, эмоциональных и иногда откровенно глупых покупок есть отдельный бюджет 😄

Главное правило: сначала отложить, потом распределять оставшееся.


3️⃣ Фиксированная сумма из каждой зарплаты — в сбережения

Не отложу то, что останется в конце месяца.
Обычно ничего не остаётся.

А сразу после получения дохода переведу установленную сумму в накопления.

Эти деньги не участвуют в повседневных расходах.


4️⃣ Использовать карты с кэшбэком и бонусами

В России для меня такой картой был Тинькофф.

И я жалею, что раньше не понимала, как правильно использовать кредитные карты.

Кредиткой можно пользоваться практически как дебетовой:

▫️ тратить только те деньги, которые уже есть
▫️ не выходить за установленный бюджет
▫️ полностью закрывать задолженность в беспроцентный период (= ежемесячно)
▫️ получать кэшбэк, мили и другие бонусы

В США я практически все расходы провожу именно так.

Но кредитная карта работает в плюс только при строгой дисциплине. Если переносить долг и платить проценты, все бонусы быстро теряют смысл.


5️⃣ До 5% годового дохода — на самообразование

Под это выделен отдельный накопительный счет. Если покупка стоит дороже накоплений, то плачу целиком и далее просто какое-то время не вношу деньги на него.

Курсы, конференции и книги - не просто расходы.

Это инвестиции, которые могут вернуться:

✅ более высокой зарплатой
✅ новыми проектами
✅ карьерным ростом
✅ развитием бизнеса
✅ более дорогой экспертизой

Но обучение должно быть осознанным: не покупать всё подряд, а понимать, какой результат оно должно принести.

И это не только про обучение в профессии.
За её пределы я тоже выхожу и это нормально.




Финансовая грамотность — это умение:
▫️ понимать, куда уходят деньги
▫️ не увеличивать расходы автоматически вместе с доходом
▫️ регулярно откладывать
▫️ разумно использовать кредитные продукты
▫️ инвестировать в своё развитие
▫️ создавать финансовую безопасность


Высокая зарплата даёт возможности.

Но только финансовая дисциплина позволяет эти возможности сохранить и превратить в капитал.


А как вы распоряжаетесь своим доходом? 💙

🚩 Двойной запрос на поиск — это не баг клиента. Это дыра в нашем ТЗ 🚩

<<Чек-лист упущенных требований>>


Типовой кейс:
маркетплейс с тысячами товаров.

Пользователь выбрал категорию, цену, бренды и рейтинг, а затем дважды нажал «Показать результаты», потому что на медленном интернете ничего не происходило.

Запрос с Frontend на Backend:

GET /products?category=electronics&brand=Apple&rating=4

или

QUERY /products 
// фильтры в JSON-объекте, в body

или

POST /products/search
// фильтры в JSON-объекте, в body

GET и QUERY — безопасные и идемпотентные методы.

POST по своей HTTP-семантике не гарантирует безопасность и идемпотентность, хотя его можно сделать таким искусственно, через требования к алгоритму работы.


Но здесь есть важный момент:
❗️ Идемпотентность не означает, что Backend выполнит два одинаковых запроса только один раз.

Она означает, что повторный вызов не должен привести к дополнительному изменению состояния системы.

Поэтому два одинаковых GET- или QUERY-запроса всё равно могут дважды запустить тяжёлый поиск.


🚩 Результат:
1. Frontend отправил два одинаковых запроса.
2. Backend дважды запустил тяжёлый поиск и фильтрацию.

⚠️ = неоптимальное использование ресурсов Backend
⚠️ = проблемы для высоконагруженной системы



Разработчик говорит:

Пользователь сам дважды нажал. Что мы сделаем?

На самом деле — многое.



🚩 Что упущено в требованиях?


👉 Требования к Frontend:

▫️ После первого нажатия показать состояние «Загрузка» и блокировать повторное нажатие

▫️ Не отправлять повторный запрос, пока выполняется предыдущий запрос с теми же параметрами

▫️ При изменении фильтров отменять предыдущий запрос или игнорировать его устаревший ответ

▫️ Не заменять актуальные данные ответом на более старый запрос, который завершился позднее


👉 Требования к Backend:

▫️ Ограничить частоту запросов от одного пользователя или клиента (rate limiting)

▫️ Кэшировать результаты одинаковых запросов с заданным TTL

▫️ При необходимости объединять одинаковые параллельные запросы, чтобы поиск выполнялся один раз

▫️ Зафиксировать таймауты и максимальное время выполнения поиска

▫️ Логировать повторные запросы и превышение установленных ограничений



❗️ Идемпотентность защищает состояние системы.
✅ Кэширование, дедупликация и rate limiting защищают её ресурсы.

Это разные свойства и разные требования.

Поэтому при проектировании API недостаточно выбрать GET, POST или QUERY. Системный аналитик должен отдельно описать, как Frontend и Backend обрабатывают повторные и параллельные запросы.

Иначе этот алгоритм команда начнёт проектировать уже после первого инцидента в проде.

#RestApiGA