🔥 HTTP-методы в REST API — с самым актуальным обновлением 2026 по QUERY 🔥
GET, POST, PUT, PATCH и DELETE знают почти все.
Но в июне 2026 года появился ещё один стандартизированный метод — QUERY. Он закрывает сценарий сложного чтения данных, для которого раньше часто использовали POST.
Собрала актуальную шпаргалку по HTTP-методам на карточках к посту: назначение, Body, идемпотентность, кэширование и примеры запросов.
🩷 GET
Получение данных, используем для получения одного ресурса или списка ресурсов.
💚 POST
Используется для создания нового объекта или запуска асинхронной операции.
💛 QUERY
Предназначен для безопасного и идемпотентного получения данных с содержимым запроса в Body.
Новый HTTP-метод, стандартизированный в июне 2026 года в RFC 10008.
Подробнее
💜 PUT
Полная замена или создание ресурса.
В Body передаётся полное представление объекта, включая поля, которые не менялись.
💙 PATCH
Частичное изменение ресурса.
В Body передаются только изменяемые поля или операции изменения.
❤️ DELETE
Удаление ресурса.
Используется для физического или логического удаления.
🤍 TRACE, HEAD, OPTIONS, CONNECT
Также существуют.
Могут быть заменены GET-ом. Используются редко.
Очень маленький шанс встретить или применить на практике.
Дополнительно для повторения может пригодиться:
подкаст про идемпотентность и коммутативность в API
Сохраняйте, это самая актуальная шпаргалка по HTTP-методам на 2026 год 👌
#RestApiGA
📱 Tg | 💙 ВК | 💬 Max
GET, POST, PUT, PATCH и DELETE знают почти все.
Но в июне 2026 года появился ещё один стандартизированный метод — QUERY. Он закрывает сценарий сложного чтения данных, для которого раньше часто использовали POST.
Собрала актуальную шпаргалку по HTTP-методам на карточках к посту: назначение, Body, идемпотентность, кэширование и примеры запросов.
🩷 GET
Получение данных, используем для получения одного ресурса или списка ресурсов.
💚 POST
Используется для создания нового объекта или запуска асинхронной операции.
💛 QUERY
Предназначен для безопасного и идемпотентного получения данных с содержимым запроса в Body.
Новый HTTP-метод, стандартизированный в июне 2026 года в RFC 10008.
Подробнее
💜 PUT
Полная замена или создание ресурса.
В Body передаётся полное представление объекта, включая поля, которые не менялись.
💙 PATCH
Частичное изменение ресурса.
В Body передаются только изменяемые поля или операции изменения.
❤️ DELETE
Удаление ресурса.
Используется для физического или логического удаления.
🤍 TRACE, HEAD, OPTIONS, CONNECT
Также существуют.
Могут быть заменены GET-ом. Используются редко.
Очень маленький шанс встретить или применить на практике.
Дополнительно для повторения может пригодиться:
подкаст про идемпотентность и коммутативность в API
Сохраняйте, это самая актуальная шпаргалка по HTTP-методам на 2026 год 👌
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19❤8⚡4
☀️ Скидка 25% на все мини-курсы: летняя неделя знаний до 24 июля ☀️
Внутри не несколько видео на 30 минут, а целые мини-курсы по 6–12 занятий, каждое из которых от 2 до 4 часов разбора задач.
Например:
▫️ БД и SQL: продвинутый уровень
Это три отдельных больших проекта с нуля: маркетплейс, страховая компания, медицинская система. В каждом — путь от анализа требований и ER-диаграммы до реальной БД, рабочих SQL и настройку ИИ-агентов.
▫️ Интеграции
практика в Postman по REST, GraphQL, gRPC, WebSocket и отдельный разбор типичных ошибок в интеграционных задачах на реальных проектах.
▫️ Архитектура
Разбор конкретных задач: как спроектировать взаимодействие между микросервисами и как выбрать между хореографией и оркестрацией в сложном асинхронном бизнес-процессе.
И другие темы.
☀️ До 24 июля — всё это на 25% дешевле
🎁 Промокод: LETO2026
👉 Смотреть каталог материалов
Формат для тех, кто предпочитает учиться самостоятельно 🤝
Вопросы? Мы на связи: @getanalyst или info@getanalyst.ru 💬
📱 Tg | 💙 ВК | 💬 Max
Внутри не несколько видео на 30 минут, а целые мини-курсы по 6–12 занятий, каждое из которых от 2 до 4 часов разбора задач.
Например:
▫️ БД и SQL: продвинутый уровень
Это три отдельных больших проекта с нуля: маркетплейс, страховая компания, медицинская система. В каждом — путь от анализа требований и ER-диаграммы до реальной БД, рабочих SQL и настройку ИИ-агентов.
▫️ Интеграции
практика в Postman по REST, GraphQL, gRPC, WebSocket и отдельный разбор типичных ошибок в интеграционных задачах на реальных проектах.
▫️ Архитектура
Разбор конкретных задач: как спроектировать взаимодействие между микросервисами и как выбрать между хореографией и оркестрацией в сложном асинхронном бизнес-процессе.
И другие темы.
☀️ До 24 июля — всё это на 25% дешевле
🎁 Промокод: LETO2026
👉 Смотреть каталог материалов
Формат для тех, кто предпочитает учиться самостоятельно 🤝
Вопросы? Мы на связи: @getanalyst или info@getanalyst.ru 💬
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
⚠️ «Настроить кэширование» — плохое требование. Вот какие 3 уровня вы упустили ⚠️
Браузер, CDN, сервер — кэш может одновременно использоваться на всех трёх уровнях.
А в требованиях чаще всего фигурирует только заголовок Cache-Control где-то на бэкенде, будто остальных двух уровней не существует.
👉 Разбираемся, что за что отвечает:
1️⃣ Клиентский кэш: браузер или мобильное приложение
Браузер может хранить HTTP-ответ локально и повторно использовать его, пока он считается актуальным.
Заголовок Cache-Control от сервера определяет, как долго ответ остаётся свежим, а заголовок ETag позволяет проверить его актуальность через условный запрос с If-None-Match. Если ресурс не изменился, сервер может вернуть 304 Not Modified без повторной передачи тела ответа.
2️⃣ CDN / edge-кэш
CDN (Content Delivery Network) — это сеть распределённых серверов, расположенных ближе к пользователям.
Она хранит копии ответов и может отдавать их без повторного обращения к основному серверу системы (origin-серверу). Один сохранённый ответ при этом может использоваться для множества пользователей.
Здесь особенно важно определить:
▫️ можно ли хранить ответ в общем кэше: public, private, no-store;
▫️ как долго он должен храниться: s-maxage, Edge TTL или другие настройки CDN;
▫️ какие параметры, заголовки и cookies входят в cache key;
▫️ нужен ли заголовок Vary;
▫️ как обрабатываются авторизованные и персонализированные ответы.
При неправильной конфигурации CDN может отдать пользователю вариант ответа, сформированный для другого контекста. Поэтому одной фразы «закэшировать ответ» недостаточно.
Отдельно нужна стратегия обновления CDN-кэша: дождаться окончания TTL, выполнить purge/invalidation или использовать версионирование URL.
3️⃣ Внутренний кэш приложения: Redis, in-memory и другие решения
Это временное хранилище данных внутри серверной части системы (Backend).
Например, сервер уже получил данные из базы и сохранил их в кэше. При следующем таком же запросе он может взять готовый результат из кэша, а не снова обращаться к базе данных или внешней системе.
Это ускоряет работу приложения и снижает нагрузку на другие компоненты.
Но возникает риск: данные в базе уже изменились, а в кэше всё ещё хранится старая версия. Тогда пользователь продолжит видеть неактуальную информацию.
Поэтому в требованиях важно определить:
▫️ какие данные можно хранить в кэше;
▫️ как долго они могут там находиться;
▫️ после каких изменений кэш нужно обновить или очистить;
▫️ насколько допустимо показывать устаревшие данные;
▫️ что должна делать система, если кэш недоступен.
📌 Фраза «настроить кэширование» без указания уровня, цели и требований к актуальности данных слишком неоднозначна.
Разработчик может реализовать тот вариант, который проще технически, но не тот, который действительно решает задачу продукта.
👉 Аналитику важно зафиксировать:
▫️ какие данные можно кэшировать и на каком уровне;
▫️ как долго они могут оставаться неактуальными;
▫️ при каких событиях кэш должен обновляться или очищаться;
▫️ что должна делать система, если кэш недоступен.
Иначе кэширование может не ускорить продукт, а стать источником устаревших данных, утечек и трудноуловимых ошибок.
А в ваших требованиях кэширование описано одной строчкой или отдельно для каждого уровня?
#RestApiGA #АрхитектураGA
📱 Tg | 💙 ВК | 💬 Max
Браузер, CDN, сервер — кэш может одновременно использоваться на всех трёх уровнях.
А в требованиях чаще всего фигурирует только заголовок Cache-Control где-то на бэкенде, будто остальных двух уровней не существует.
👉 Разбираемся, что за что отвечает:
1️⃣ Клиентский кэш: браузер или мобильное приложение
Браузер может хранить HTTP-ответ локально и повторно использовать его, пока он считается актуальным.
Заголовок Cache-Control от сервера определяет, как долго ответ остаётся свежим, а заголовок ETag позволяет проверить его актуальность через условный запрос с If-None-Match. Если ресурс не изменился, сервер может вернуть 304 Not Modified без повторной передачи тела ответа.
2️⃣ CDN / edge-кэш
CDN (Content Delivery Network) — это сеть распределённых серверов, расположенных ближе к пользователям.
Она хранит копии ответов и может отдавать их без повторного обращения к основному серверу системы (origin-серверу). Один сохранённый ответ при этом может использоваться для множества пользователей.
Здесь особенно важно определить:
▫️ можно ли хранить ответ в общем кэше: public, private, no-store;
▫️ как долго он должен храниться: s-maxage, Edge TTL или другие настройки CDN;
▫️ какие параметры, заголовки и cookies входят в cache key;
▫️ нужен ли заголовок Vary;
▫️ как обрабатываются авторизованные и персонализированные ответы.
При неправильной конфигурации CDN может отдать пользователю вариант ответа, сформированный для другого контекста. Поэтому одной фразы «закэшировать ответ» недостаточно.
Отдельно нужна стратегия обновления CDN-кэша: дождаться окончания TTL, выполнить purge/invalidation или использовать версионирование URL.
3️⃣ Внутренний кэш приложения: Redis, in-memory и другие решения
Это временное хранилище данных внутри серверной части системы (Backend).
Например, сервер уже получил данные из базы и сохранил их в кэше. При следующем таком же запросе он может взять готовый результат из кэша, а не снова обращаться к базе данных или внешней системе.
Это ускоряет работу приложения и снижает нагрузку на другие компоненты.
Но возникает риск: данные в базе уже изменились, а в кэше всё ещё хранится старая версия. Тогда пользователь продолжит видеть неактуальную информацию.
Поэтому в требованиях важно определить:
▫️ какие данные можно хранить в кэше;
▫️ как долго они могут там находиться;
▫️ после каких изменений кэш нужно обновить или очистить;
▫️ насколько допустимо показывать устаревшие данные;
▫️ что должна делать система, если кэш недоступен.
📌 Фраза «настроить кэширование» без указания уровня, цели и требований к актуальности данных слишком неоднозначна.
Разработчик может реализовать тот вариант, который проще технически, но не тот, который действительно решает задачу продукта.
👉 Аналитику важно зафиксировать:
▫️ какие данные можно кэшировать и на каком уровне;
▫️ как долго они могут оставаться неактуальными;
▫️ при каких событиях кэш должен обновляться или очищаться;
▫️ что должна делать система, если кэш недоступен.
Иначе кэширование может не ускорить продукт, а стать источником устаревших данных, утечек и трудноуловимых ошибок.
А в ваших требованиях кэширование описано одной строчкой или отдельно для каждого уровня?
#RestApiGA #АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤17🔥8👍3
📌 Шпаргалка по свойствам HTTP-методов: безопасность, идемпотентность, кэшируемость и тело JSON 📌
В англоязычной Wikipedia уже обновили таблицу свойств HTTP-методов: в ней появился новый метод QUERY, описанный в RFC 10008.
https://en.wikipedia.org/wiki/HTTP#Request_methods
Эта таблица — моя вечная шпаргалка для подготовки к собеседованиям.
Свойства методов из таблицы 👇
📤 Запрос может содержать тело — Request payload
Показывает, может ли запрос содержать данные в body.
Для POST, PUT, PATCH и QUERY тело является обычной частью запроса.
Для GET, HEAD и DELETE тело технически может быть передано, но его общая семантика стандартом не определена. Более того, некоторые серверы и промежуточные компоненты могут отклонить такой запрос.
📥 Ответ может содержать тело — Response payload
Показывает, может ли сервер вернуть данные в body.
Например, HEAD возвращает только заголовки.
У ответов 204 No Content и 304 Not Modified тела быть не должно.
🛡 Safe — безопасный
Метод считается безопасным, если клиент не запрашивает изменение состояния целевого ресурса.
Например:
▫️ GET получает данные
▫️ HEAD получает заголовки
▫️ QUERY получает данные
При этом логирование, сбор статистики и другие внутренние побочные действия сервера не делают метод небезопасным.
🔁 Idempotent — идемпотентный
Несколько одинаковых запросов должны иметь тот же ожидаемый эффект, что и один.
Например, первый DELETE может вернуть 204, а повторный — 404, но ресурс в обоих случаях удалён.
POST и PATCH по умолчанию не считаются идемпотентными.
🗄 Cacheable — кэшируемый
Ответ можно сохранить и повторно использовать по правилам HTTP-кэширования.
Это зависит от:
▫️ Cache-Control
▫️ клиента и сервера
▫️ CDN и прокси
▫️ реализации метода
Даже POST и PATCH могут кэшироваться при выполнении специальных условий. Спорные случаи лучше проверять по RFC.
Сохраняйте, если готовитесь к собеседованиям или изучаете HTTP и REST API 💙
#RestApiGA
📱 Tg | 💙 ВК | 💬 Max
В англоязычной Wikipedia уже обновили таблицу свойств HTTP-методов: в ней появился новый метод QUERY, описанный в RFC 10008.
https://en.wikipedia.org/wiki/HTTP#Request_methods
Эта таблица — моя вечная шпаргалка для подготовки к собеседованиям.
Свойства методов из таблицы 👇
📤 Запрос может содержать тело — Request payload
Показывает, может ли запрос содержать данные в body.
Для POST, PUT, PATCH и QUERY тело является обычной частью запроса.
Для GET, HEAD и DELETE тело технически может быть передано, но его общая семантика стандартом не определена. Более того, некоторые серверы и промежуточные компоненты могут отклонить такой запрос.
📥 Ответ может содержать тело — Response payload
Показывает, может ли сервер вернуть данные в body.
Например, HEAD возвращает только заголовки.
У ответов 204 No Content и 304 Not Modified тела быть не должно.
🛡 Safe — безопасный
Метод считается безопасным, если клиент не запрашивает изменение состояния целевого ресурса.
Например:
▫️ GET получает данные
▫️ HEAD получает заголовки
▫️ QUERY получает данные
При этом логирование, сбор статистики и другие внутренние побочные действия сервера не делают метод небезопасным.
🔁 Idempotent — идемпотентный
Несколько одинаковых запросов должны иметь тот же ожидаемый эффект, что и один.
Например, первый DELETE может вернуть 204, а повторный — 404, но ресурс в обоих случаях удалён.
POST и PATCH по умолчанию не считаются идемпотентными.
🗄 Cacheable — кэшируемый
Ответ можно сохранить и повторно использовать по правилам HTTP-кэширования.
Это зависит от:
▫️ Cache-Control
▫️ клиента и сервера
▫️ CDN и прокси
▫️ реализации метода
Даже POST и PATCH могут кэшироваться при выполнении специальных условий. Спорные случаи лучше проверять по RFC.
Сохраняйте, если готовитесь к собеседованиям или изучаете HTTP и REST API 💙
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15❤10
🔴 "no-cache" не означает «не кэшировать»: 4 директивы заголовка Cache-Control, которые важно различать 🔴
Посмотрите на заголовок (header):
Кажется, что ответ нельзя сохранить в кэше.
Но на самом деле no-cache означает другое.
Разбираемся подробно, чем отличаются основные директивы Cache-Control 👇
1️⃣ no-cache
Сохранить можно, использовать без проверки нельзя.
Клиент может сохранить ответ.
Но при следующем обращении он должен спросить у сервера «Версия
Если данные не изменились, сервер вернёт:
И клиент использует сохранённый ответ.
2️⃣
Сохранять нельзя вообще.
Запрос и ответ не должны сохраняться в HTTP-кэше.
Обычно используется для чувствительных данных:
▫️ токенов
▫️ одноразовых кодов
▫️ платёжной информации
▫️ результатов аутентификации
3️⃣
Хранить можно только в персональном кэше.
Ответ может сохранить браузер конкретного пользователя.
Но общий кэш — например, CDN или Proxy — не должен сохранять его для других клиентов.
Подходит для персонализированных данных:
4️⃣
Ответ можно хранить в общем кэше
Ответ могут сохранять не только браузеры, но и общие кэши:
▫️ CDN
▫️ Reverse Proxy
▫️ API Gateway
Подходит для публичных данных:
▫️ справочников
▫️ статей
▫️ общего каталога
▫️ публичной конфигурации
Что должен определить системный аналитик при разработке требований к кэшу, чтобы Cache-Control помогал, а не вредил системе:
:
✅ можно ли вообще сохранять ответ
✅ допустим ли кэш только на устройстве пользователя
✅ можно ли использовать общий кэш
✅ нужна ли проверка актуальности перед использованием
✅ содержит ли ответ персональные или чувствительные данные
От него зависят актуальность и безопасность данных 👌
#RestApiGA
Посмотрите на заголовок (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
👍20❤6
🔥 Завтра летняя неделя знаний заканчивается: -25% на обучения в GetAnalyst 🔥
Обычно я сама читаю такие посты и думаю «успею позже». А потом дедлайн проходит, и всё 🙃
Поэтому пишу заранее, а не в последний час.
Сегодня и завтра последний шанс забрать мини-курсы на 25% дешевле:
✔️ разборы задач с проектов
✔️ чек-листы и шаблоны, обкатанные на живых командах
✔️ подготовка к собеседованиям
Темы:
▫️ Интеграции
▫️ REST API
▫️ Архитектура
▫️ БД и SQL, ER-диаграммы
▫️ Резюме и собеседования
▫️ Анализ требований
📌 Скидка 25%
🗓 Только сегодня и завтра
🎁 Промокод: LETO2026
👉 Забрать материалы со скидкой
Вопросы по материалам? Пишите @getanalyst или info@getanalyst.ru 🤝
📱 Tg | 💙 ВК | 💬 Max
Обычно я сама читаю такие посты и думаю «успею позже». А потом дедлайн проходит, и всё 🙃
Поэтому пишу заранее, а не в последний час.
Сегодня и завтра последний шанс забрать мини-курсы на 25% дешевле:
✔️ разборы задач с проектов
✔️ чек-листы и шаблоны, обкатанные на живых командах
✔️ подготовка к собеседованиям
Темы:
▫️ Интеграции
▫️ REST API
▫️ Архитектура
▫️ БД и SQL, ER-диаграммы
▫️ Резюме и собеседования
▫️ Анализ требований
📌 Скидка 25%
🗓 Только сегодня и завтра
🎁 Промокод: LETO2026
👉 Забрать материалы со скидкой
Вопросы по материалам? Пишите @getanalyst или info@getanalyst.ru 🤝
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1
💸 Высокая ЗП в IT ещё не означает, что у вас останутся деньги 💸
Можно хорошо зарабатывать и всё равно жить от зарплаты до зарплаты.
Моя стратегия другая: сначала создать базу для накоплений, а уже потом тратить оставшееся.
Именно благодаря этому подходу я:
+ купила первую машину из салона в 19 лет,
+ впервые отправила себя учиться в США в 23 года,
+ купила первую квартиру у моря в 24 года и погасила ипотеку на неё за 2 года,
+ объехала почти 20 стран,
+ всё без кредитов, кроме недвижимости.
И всё это работая в найме системным аналитиком.
Сейчас я продолжаю формировать накопления и капитал, придерживаясь привычек, которые со мной с раннего возраста.
Вот 5 принципов, которые всегда со мной 👇
1️⃣ Инвестировать, а не просто хранить деньги
Часть накоплений я направляю в инвестиции.
Не ради быстрого заработка, а чтобы деньги работали в долгосрочной перспективе и не лежали без движения.
Именно эта стратегия помогла мне накопить на первую квартиру.
2️⃣ Постоянно учитывать доходы и расходы
Я веду учёт финансов и заранее устанавливаю лимиты на месяц.
Это не значит запрещать себе всё.
Я покупаю то, что действительно важно и нужно. А для необязательных, эмоциональных и иногда откровенно глупых покупок есть отдельный бюджет 😄
Главное правило: сначала отложить, потом распределять оставшееся.
3️⃣ Фиксированная сумма из каждой зарплаты — в сбережения
Не отложу то, что останется в конце месяца.
Обычно ничего не остаётся.
А сразу после получения дохода переведу установленную сумму в накопления.
Эти деньги не участвуют в повседневных расходах.
4️⃣ Использовать карты с кэшбэком и бонусами
В России для меня такой картой был Тинькофф.
И я жалею, что раньше не понимала, как правильно использовать кредитные карты.
Кредиткой можно пользоваться практически как дебетовой:
▫️ тратить только те деньги, которые уже есть
▫️ не выходить за установленный бюджет
▫️ полностью закрывать задолженность в беспроцентный период (= ежемесячно)
▫️ получать кэшбэк, мили и другие бонусы
В США я практически все расходы провожу именно так.
Но кредитная карта работает в плюс только при строгой дисциплине. Если переносить долг и платить проценты, все бонусы быстро теряют смысл.
5️⃣ До 5% годового дохода — на самообразование
Под это выделен отдельный накопительный счет. Если покупка стоит дороже накоплений, то плачу целиком и далее просто какое-то время не вношу деньги на него.
Курсы, конференции и книги - не просто расходы.
Это инвестиции, которые могут вернуться:
✅ более высокой зарплатой
✅ новыми проектами
✅ карьерным ростом
✅ развитием бизнеса
✅ более дорогой экспертизой
Но обучение должно быть осознанным: не покупать всё подряд, а понимать, какой результат оно должно принести.
И это не только про обучение в профессии.
За её пределы я тоже выхожу и это нормально.
Финансовая грамотность — это умение:
▫️ понимать, куда уходят деньги
▫️ не увеличивать расходы автоматически вместе с доходом
▫️ регулярно откладывать
▫️ разумно использовать кредитные продукты
▫️ инвестировать в своё развитие
▫️ создавать финансовую безопасность
Высокая зарплата даёт возможности.
Но только финансовая дисциплина позволяет эти возможности сохранить и превратить в капитал.
А как вы распоряжаетесь своим доходом? 💙
Можно хорошо зарабатывать и всё равно жить от зарплаты до зарплаты.
Моя стратегия другая: сначала создать базу для накоплений, а уже потом тратить оставшееся.
Именно благодаря этому подходу я:
+ купила первую машину из салона в 19 лет,
+ впервые отправила себя учиться в США в 23 года,
+ купила первую квартиру у моря в 24 года и погасила ипотеку на неё за 2 года,
+ объехала почти 20 стран,
+ всё без кредитов, кроме недвижимости.
И всё это работая в найме системным аналитиком.
Сейчас я продолжаю формировать накопления и капитал, придерживаясь привычек, которые со мной с раннего возраста.
Вот 5 принципов, которые всегда со мной 👇
1️⃣ Инвестировать, а не просто хранить деньги
Часть накоплений я направляю в инвестиции.
Не ради быстрого заработка, а чтобы деньги работали в долгосрочной перспективе и не лежали без движения.
Именно эта стратегия помогла мне накопить на первую квартиру.
2️⃣ Постоянно учитывать доходы и расходы
Я веду учёт финансов и заранее устанавливаю лимиты на месяц.
Это не значит запрещать себе всё.
Я покупаю то, что действительно важно и нужно. А для необязательных, эмоциональных и иногда откровенно глупых покупок есть отдельный бюджет 😄
Главное правило: сначала отложить, потом распределять оставшееся.
3️⃣ Фиксированная сумма из каждой зарплаты — в сбережения
Не отложу то, что останется в конце месяца.
Обычно ничего не остаётся.
А сразу после получения дохода переведу установленную сумму в накопления.
Эти деньги не участвуют в повседневных расходах.
4️⃣ Использовать карты с кэшбэком и бонусами
В России для меня такой картой был Тинькофф.
И я жалею, что раньше не понимала, как правильно использовать кредитные карты.
Кредиткой можно пользоваться практически как дебетовой:
▫️ тратить только те деньги, которые уже есть
▫️ не выходить за установленный бюджет
▫️ полностью закрывать задолженность в беспроцентный период (= ежемесячно)
▫️ получать кэшбэк, мили и другие бонусы
В США я практически все расходы провожу именно так.
Но кредитная карта работает в плюс только при строгой дисциплине. Если переносить долг и платить проценты, все бонусы быстро теряют смысл.
5️⃣ До 5% годового дохода — на самообразование
Под это выделен отдельный накопительный счет. Если покупка стоит дороже накоплений, то плачу целиком и далее просто какое-то время не вношу деньги на него.
Курсы, конференции и книги - не просто расходы.
Это инвестиции, которые могут вернуться:
✅ более высокой зарплатой
✅ новыми проектами
✅ карьерным ростом
✅ развитием бизнеса
✅ более дорогой экспертизой
Но обучение должно быть осознанным: не покупать всё подряд, а понимать, какой результат оно должно принести.
И это не только про обучение в профессии.
За её пределы я тоже выхожу и это нормально.
Финансовая грамотность — это умение:
▫️ понимать, куда уходят деньги
▫️ не увеличивать расходы автоматически вместе с доходом
▫️ регулярно откладывать
▫️ разумно использовать кредитные продукты
▫️ инвестировать в своё развитие
▫️ создавать финансовую безопасность
Высокая зарплата даёт возможности.
Но только финансовая дисциплина позволяет эти возможности сохранить и превратить в капитал.
А как вы распоряжаетесь своим доходом? 💙
🔥49❤28👍8😁2💯2🤔1
🌴 До сих пор не верю, что пишу этот пост с островов посреди Тихого океана.
Я завершаю отпуск на Гавайях. До переезда в США они казались мне чем-то совершенно недостижимым. Да и сейчас, если честно, сложно поверить, что я наконец-то здесь.
Ещё один штат покорён. Ещё одна мечта исполнена. Новый заряд вдохновения получен 💙
Мы слишком часто ждём выгорания, чтобы наконец разрешить себе отдохнуть.
Хотя иногда лучший способ снова захотеть что-то делать — на время перестать что-то делать.
Не забывайте отдыхать.
Кто сейчас отдыхает или уже успел отдохнуть — ставьте ❤️
У кого отпуск ещё впереди — 🔥
Я завершаю отпуск на Гавайях. До переезда в США они казались мне чем-то совершенно недостижимым. Да и сейчас, если честно, сложно поверить, что я наконец-то здесь.
Ещё один штат покорён. Ещё одна мечта исполнена. Новый заряд вдохновения получен 💙
Мы слишком часто ждём выгорания, чтобы наконец разрешить себе отдохнуть.
Хотя иногда лучший способ снова захотеть что-то делать — на время перестать что-то делать.
Не забывайте отдыхать.
Кто сейчас отдыхает или уже успел отдохнуть — ставьте ❤️
У кого отпуск ещё впереди — 🔥
❤62🔥51🥰5❤🔥3
🚩 Двойной запрос на поиск — это не баг клиента. Это дыра в нашем ТЗ 🚩
<<Чек-лист упущенных требований>>
Типовой кейс:
маркетплейс с тысячами товаров.
Пользователь выбрал категорию, цену, бренды и рейтинг, а затем дважды нажал «Показать результаты», потому что на медленном интернете ничего не происходило.
Запрос с Frontend на Backend:
или
или
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
<<Чек-лист упущенных требований>>
Типовой кейс:
маркетплейс с тысячами товаров.
Пользователь выбрал категорию, цену, бренды и рейтинг, а затем дважды нажал «Показать результаты», потому что на медленном интернете ничего не происходило.
Запрос с 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
❤30💯3