📌 Проси много, чтобы получить хотя бы половину 📌
Это моя фраза недели.
Мне кажется, она очень хорошо ложится не только на бизнес, но и на карьеру, зарплату и профессиональный рост.
Мы часто сами себя занижаем:
▫️ «мне ещё рано»
▫️ «я пока не дотягиваю»
▫️ «а вдруг откажут»
▫️ «а вдруг я прошу слишком много»
Особенно сейчас, когда вокруг много тревоги, нестабильности и разговоров про кризис.
А потом удивляемся, почему нас оценивают ниже, чем хотелось бы?!
Иногда рост начинается не с нового курса, новой работы или нового проекта.
👉 А с внутреннего разрешения перестать торговаться против себя.
Просить больше.
Называть сумму смелее.
Не обесценивать свой опыт.
Не объяснять себе самому заранее, почему вам можно заплатить меньше.
Потому что если вы сами ставите себе нижнюю планку, рынок редко будет спорить и поднимать её за вас.
👉 Рост часто начинается там, где вы перестаёте себя уменьшать.
И если вы хотя читаете этот канал, думаете о профессии, задаёте вопросы, учитесь и развиваетесь — это уже не «ничего особенного».
Это уже вклад в вашу будущую стоимость как специалиста.
P.S. А к посту добавила подборку доброты, которая скопилась за последние пару месяцев. Здесь поместилось меньше половины 🩷🩷🩷 Огромная благодарность за каждое сообщение 🙏
📱 Tg | 💙 ВК | 💬 Max
Это моя фраза недели.
Мне кажется, она очень хорошо ложится не только на бизнес, но и на карьеру, зарплату и профессиональный рост.
Мы часто сами себя занижаем:
▫️ «мне ещё рано»
▫️ «я пока не дотягиваю»
▫️ «а вдруг откажут»
▫️ «а вдруг я прошу слишком много»
Особенно сейчас, когда вокруг много тревоги, нестабильности и разговоров про кризис.
А потом удивляемся, почему нас оценивают ниже, чем хотелось бы?!
Иногда рост начинается не с нового курса, новой работы или нового проекта.
👉 А с внутреннего разрешения перестать торговаться против себя.
Просить больше.
Называть сумму смелее.
Не обесценивать свой опыт.
Не объяснять себе самому заранее, почему вам можно заплатить меньше.
Потому что если вы сами ставите себе нижнюю планку, рынок редко будет спорить и поднимать её за вас.
👉 Рост часто начинается там, где вы перестаёте себя уменьшать.
И если вы хотя читаете этот канал, думаете о профессии, задаёте вопросы, учитесь и развиваетесь — это уже не «ничего особенного».
Это уже вклад в вашу будущую стоимость как специалиста.
P.S. А к посту добавила подборку доброты, которая скопилась за последние пару месяцев. Здесь поместилось меньше половины 🩷🩷🩷 Огромная благодарность за каждое сообщение 🙏
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥29💯9🦄7❤3🔥1
GetAnalyst_Параметры_в_запросах_REST_API_HTTP.png
2.2 MB
✍️ 3 вида параметров HTTP, где чаще всего ошибаются аналитики ✍️
Гайд по параметрам HTTP (REST API) запросов, в которых чаще всего путаются новички:
👉 query — после ? в URL.
Используются для:
+ фильтров,
+ сортировки,
+ пагинации (limit+offset),
+ api-key (если так принято).
Получить список пользователей с именем "Иван", 10 записей, начиная с 20-ой, сортировать по алфавиту А -> Я.
Типичные проблемы:
• Отправляют бизнес-данные для создания/изменения в query, вместо использования тела json.
• Добавляют query в POST/PUT без причины.
👉 path — часть пути (эндпоинта).
Идентификатор конкретного ресурса.
Можно внутри пути, когда иерархия:
Типичные проблемы:
• Отправляют ?userId=… в query, хотя это выбор сущности по id, а не фильтр.
👉 body — тело запроса json.
Сообщение, когда создаём/меняем данные.
Только для POST | PUT | PATCH.
Кроме json могут быть другие форматы.
Типичные проблемы:
• Отправляют огромное количество параметров в query, которые там не помещаются, и могут быть обрезаны сервером при определенных настройках безопасности.
• Используют body(json) для GET или DELETE, где оно не поддержано.
В гайде:
✔️ название параметра и его определение
✔️ скрины из Postman
✔️ особенности
✔️ примеры
Изучайте, запоминайте и не путайтесь 🤝
#RestApiGA
📱 Tg | 💙 ВК | 💬 Max
Гайд по параметрам HTTP (REST API) запросов, в которых чаще всего путаются новички:
👉 query — после ? в URL.
Используются для:
+ фильтров,
+ сортировки,
+ пагинации (limit+offset),
+ api-key (если так принято).
GET /users?name=Иван&limit=10&offset=20&order=name,asc
Получить список пользователей с именем "Иван", 10 записей, начиная с 20-ой, сортировать по алфавиту А -> Я.
Типичные проблемы:
• Отправляют бизнес-данные для создания/изменения в query, вместо использования тела json.
• Добавляют query в POST/PUT без причины.
👉 path — часть пути (эндпоинта).
Идентификатор конкретного ресурса.
GET /users/{userId}
→ GET /users/12345
Можно внутри пути, когда иерархия:
PATCH /users/{userId}/archive
Типичные проблемы:
• Отправляют ?userId=… в query, хотя это выбор сущности по id, а не фильтр.
👉 body — тело запроса json.
Сообщение, когда создаём/меняем данные.
Только для POST | PUT | PATCH.
Кроме json могут быть другие форматы.
{
"name": "Петр",
"lastname": "Иванов",
"bio": "Любитель системного анализа"
}
Типичные проблемы:
• Отправляют огромное количество параметров в query, которые там не помещаются, и могут быть обрезаны сервером при определенных настройках безопасности.
• Используют body(json) для GET или DELETE, где оно не поддержано.
В гайде:
✔️ название параметра и его определение
✔️ скрины из Postman
✔️ особенности
✔️ примеры
Изучайте, запоминайте и не путайтесь 🤝
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤22🔥3⚡1👍1
🤔 Разница в HTTP, REST и RESTful API 🤔
Вопросы “Что такое REST API?” или “Что такое RESTful API?” в разных вариациях и формулировках задают на технических собеседованиях системных аналитиков 👀
Чтобы уверенно отвечать на них и глубоко понимать значение REST API, необходимо знать этот набор определений:
1️⃣ API — это программный интерфейс для обмена данными между приложениями:
• мобильное приложение ↔ сервер
• сайт ↔ сервер
• один backend-сервис ↔ другой backend-сервис
• внутренняя система ↔ внешняя система
API определяет, как одна система может обратиться к другой: какие запросы отправлять, какие данные передавать и какие ответы получать.
2️⃣ HTTP — это один из основных протоколов обмена данными в Интернете.
Он определяет, как клиент и сервер обмениваются сообщениями:
• клиент отправляет запрос
• сервер обрабатывает его
• сервер возвращает ответ
HTTP включает:
• методы: GET, POST, PUT, PATCH, DELETE и другие
• статус-коды: 200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 Internal Server Error и другие
• заголовки
• тело запроса и ответа
Важно: HTTP сам по себе ещё не делает API REST API.
Можно сделать HTTP API, где все методы будут через POST, с глаголами в URL и без нормальной ресурсной модели.
Например:
Это будет HTTP API, но не REST API.
3️⃣ REST (Representational State Transfer) — это архитектурный стиль для проектирования сетевых API.
Проще говоря, REST задаёт подход:
как правильно организовать взаимодействие клиента и сервера через ресурсы.
В REST данные представляются как ресурсы.
Например:
С этими ресурсами выполняются действия через HTTP-методы:
То есть мы не пишем действие в URL, а используем связку:
Если этот принцип не соблюдается, то это чаще просто HTTP API, а не REST API.
4️⃣ REST API — архитектурный стиль проектирования программных интерфейсов.
Такой API:
• работает с ресурсами
• использует HTTP-методы по смыслу
• адресует ресурсы через URL
• возвращает данные в удобном для клиента формате, чаще всего JSON
• использует HTTP-статусы для описания результата операции
Пример:
5️⃣ RESTful API — это термин, который подчеркивает строгое следование принципам REST.
То есть, когда мы говорим, что API является "RESTful", мы хотим сказать, что он полностью соответствует архитектурным стилям и ограничениям, определенным в REST.
Это подразумевает, что API не только использует HTTP-методы и работает через URL, но и строго следует всем рекомендациям и лучшим практикам REST.
👉 По сути
HTTP — это протокол передачи данных.
REST — архитектурный стиль.
REST API — API, сделанный по принципам REST.
RESTful API — API, который подчёркнуто следует REST-подходу.
👉 В повседневной разработке эти различия зачастую стираются, и термины используются как синонимы.
Но на собеседовании лучше показать, что вы понимаете разницу:
🔹 не любой HTTP API является REST API,
🔹 но REST API обычно использует HTTP.
Желаю вам успешных технических собеседований 😉
#RestApiGA
Вопросы “Что такое REST API?” или “Что такое RESTful API?” в разных вариациях и формулировках задают на технических собеседованиях системных аналитиков 👀
Чтобы уверенно отвечать на них и глубоко понимать значение REST API, необходимо знать этот набор определений:
1️⃣ API — это программный интерфейс для обмена данными между приложениями:
• мобильное приложение ↔ сервер
• сайт ↔ сервер
• один backend-сервис ↔ другой backend-сервис
• внутренняя система ↔ внешняя система
API определяет, как одна система может обратиться к другой: какие запросы отправлять, какие данные передавать и какие ответы получать.
2️⃣ HTTP — это один из основных протоколов обмена данными в Интернете.
Он определяет, как клиент и сервер обмениваются сообщениями:
• клиент отправляет запрос
• сервер обрабатывает его
• сервер возвращает ответ
HTTP включает:
• методы: GET, POST, PUT, PATCH, DELETE и другие
• статус-коды: 200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 Internal Server Error и другие
• заголовки
• тело запроса и ответа
Важно: HTTP сам по себе ещё не делает API REST API.
Можно сделать HTTP API, где все методы будут через POST, с глаголами в URL и без нормальной ресурсной модели.
Например:
POST /createUser
POST /getUserInfo
POST /deleteUser
Это будет HTTP API, но не REST API.
3️⃣ REST (Representational State Transfer) — это архитектурный стиль для проектирования сетевых API.
Проще говоря, REST задаёт подход:
как правильно организовать взаимодействие клиента и сервера через ресурсы.
В REST данные представляются как ресурсы.
Например:
/users
/users/{userId}
/orders
/orders/{orderId}
С этими ресурсами выполняются действия через HTTP-методы:
GET /users/{userId}
POST /users
PUT /users/{userId}
PATCH /users/{userId}
DELETE /users/{userId}
То есть мы не пишем действие в URL, а используем связку:
HTTP-метод + ресурс
Если этот принцип не соблюдается, то это чаще просто HTTP API, а не REST API.
4️⃣ REST API — архитектурный стиль проектирования программных интерфейсов.
Такой API:
• работает с ресурсами
• использует HTTP-методы по смыслу
• адресует ресурсы через URL
• возвращает данные в удобном для клиента формате, чаще всего JSON
• использует HTTP-статусы для описания результата операции
Пример:
GET /api/v1/products
GET /api/v1/products/{productId}
POST /api/v1/products
PATCH /api/v1/products/{productId}
DELETE /api/v1/products/{productId}
5️⃣ RESTful API — это термин, который подчеркивает строгое следование принципам REST.
То есть, когда мы говорим, что API является "RESTful", мы хотим сказать, что он полностью соответствует архитектурным стилям и ограничениям, определенным в REST.
Это подразумевает, что API не только использует HTTP-методы и работает через URL, но и строго следует всем рекомендациям и лучшим практикам REST.
👉 По сути
HTTP — это протокол передачи данных.
REST — архитектурный стиль.
REST API — API, сделанный по принципам REST.
RESTful API — API, который подчёркнуто следует REST-подходу.
👉 В повседневной разработке эти различия зачастую стираются, и термины используются как синонимы.
Но на собеседовании лучше показать, что вы понимаете разницу:
🔹 не любой HTTP API является REST API,
🔹 но REST API обычно использует HTTP.
Желаю вам успешных технических собеседований 😉
#RestApiGA
🔥24❤9👍7😁1
🔥 19 мая — последний онлайн-поток по REST API перед годовым перерывом 🔥
Открываем предзапись на практическую программу для системных и бизнес-аналитиков:
📌 Дизайн REST API
🗓 Старт — 19 мая 2026
🎁 Лучшие условия действуют только до 12 мая:
✅ сниженная стоимость участия
✅ мини-курс по Архитектуре в подарок
✅ +1 дополнительный месяц доступа к материалам курса
🔗 Узнать подробности и записаться
Это последний живой поток в этом году. Следующий в мае 2027 года.
Мы переходим к формату, где живое обучение по REST API будет проходить 1 раз в год.
В течение года курс можно будет проходить самостоятельно по записям.
👉 По сути, это последний шанс в этом году пройти REST API в полном формате: с живыми занятиями, практикой, обратной связью, разбором ошибок и возможностью задавать вопросы.
На программе учимся проектировать REST API так, как это нужно системному аналитику в реальной работе:
▫️ выбирать GET / POST / PUT / PATCH / DELETE
▫️ проектировать URL, path/query-параметры, headers и JSON body
▫️ описывать HTTP-коды и обработку ошибок
▫️ работать с Postman, Insomnia, Swagger / OpenAPI
▫️ описывать авторизацию и требования к API
▫️ готовить постановки задач для backend-разработчиков
✅ По итогам: собираете REST API-проект для портфолио
Это не курс “посмотреть видео про REST”.
Это практическое обучение, где вы руками проектируете API, разбираете ошибки и учитесь мыслить через ресурсы, контракты, сценарии и ограничения системы.
🟢 После основного онлайн-потока участникам будут доступны дополнительные ежемесячные встречи на сложные темы:
▫️ ИИ в работе с REST API
▫️ GraphQL после REST
▫️ кэширование в API
▫️ задачи к собеседованиям
▫️ дополнительные разборы практических кейсов
📌 Кому актуально:
✔️ если на работе вам уже прилетают задачи по API, но вы не до конца уверены в своих решениях
✔️ если на собеседованиях спрашивают REST, HTTP, JSON, Postman, Swagger, а ответы пока звучат неуверенно
✔️ если хотите перейти от “я примерно понимаю API” к “я могу сам спроектировать метод и описать его для разработки”
✔️ если хотите расти в backend: интеграции, микросервисы и архитектуру.
REST API — один из базовых технических навыков аналитика.
Без него сложно уверенно работать с интеграциями, backend и архитектурой систем.
Текущий поток — хороший момент закрыть эту тему системно: не отдельными статьями и кусками из разных источников, а через живую практику, проект, обратную связь и понятную структуру обучения 🤝
Нужна консультация по программе? Пишите в ЛС @getanalyst или через сайт💬
Открываем предзапись на практическую программу для системных и бизнес-аналитиков:
📌 Дизайн REST API
🎁 Лучшие условия действуют только до 12 мая:
✅ сниженная стоимость участия
✅ мини-курс по Архитектуре в подарок
✅ +1 дополнительный месяц доступа к материалам курса
Это последний живой поток в этом году. Следующий в мае 2027 года.
Мы переходим к формату, где живое обучение по REST API будет проходить 1 раз в год.
В течение года курс можно будет проходить самостоятельно по записям.
👉 По сути, это последний шанс в этом году пройти REST API в полном формате: с живыми занятиями, практикой, обратной связью, разбором ошибок и возможностью задавать вопросы.
На программе учимся проектировать REST API так, как это нужно системному аналитику в реальной работе:
▫️ выбирать GET / POST / PUT / PATCH / DELETE
▫️ проектировать URL, path/query-параметры, headers и JSON body
▫️ описывать HTTP-коды и обработку ошибок
▫️ работать с Postman, Insomnia, Swagger / OpenAPI
▫️ описывать авторизацию и требования к API
▫️ готовить постановки задач для backend-разработчиков
✅ По итогам: собираете REST API-проект для портфолио
Это не курс “посмотреть видео про REST”.
Это практическое обучение, где вы руками проектируете API, разбираете ошибки и учитесь мыслить через ресурсы, контракты, сценарии и ограничения системы.
🟢 После основного онлайн-потока участникам будут доступны дополнительные ежемесячные встречи на сложные темы:
▫️ ИИ в работе с REST API
▫️ GraphQL после REST
▫️ кэширование в API
▫️ задачи к собеседованиям
▫️ дополнительные разборы практических кейсов
📌 Кому актуально:
✔️ если на работе вам уже прилетают задачи по API, но вы не до конца уверены в своих решениях
✔️ если на собеседованиях спрашивают REST, HTTP, JSON, Postman, Swagger, а ответы пока звучат неуверенно
✔️ если хотите перейти от “я примерно понимаю API” к “я могу сам спроектировать метод и описать его для разработки”
✔️ если хотите расти в backend: интеграции, микросервисы и архитектуру.
REST API — один из базовых технических навыков аналитика.
Без него сложно уверенно работать с интеграциями, backend и архитектурой систем.
Текущий поток — хороший момент закрыть эту тему системно: не отдельными статьями и кусками из разных источников, а через живую практику, проект, обратную связь и понятную структуру обучения 🤝
Нужна консультация по программе? Пишите в ЛС @getanalyst или через сайт
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍1
Headers – заголовки запроса и ответа в протоколе HTTP.
Это дополнительные системные параметры, которыми надо обмениваться. Обычно сквозные для всех методов в API, то есть применяются сразу для всех методов.
Помогают:
✔️ Определять, как обрабатывать запрос.
✔️ Передавать метаинформацию о данных (системную).
✔️ Настраивать взаимодействие между клиентом и сервером.
Проще всего разобраться с Headers, познакомившись с набором стандартных значений, которые можно нагло копировать в требования к вашим REST API методам 🙂
📌 Request Headers - для запросов
◽️ Authorization
Используется для передачи токенов доступа, ключей API или других данных для авторизации. Используется для проверки доступа к API-методам.
Authorization: Bearer <token>
◽️ Content-Type
Сообщает серверу, в каком формате отправлены данные.
Если сервер не знает в каком формате переданы данные, то он не сможет обработать запрос.
Если его нет в API, то сервер обычно ждёт JSON, если в документации не указано иное.
Content-Type: application/json
Content-Type: application/xml
◽️ Cache-Control
Управляет кэшированием данных на клиенте.
Полезно для работы с экономией трафика.
Cache-Control: no-cache
◽️ Ключи идемпотентности - название придумываете сами
Это уникальный идентификатор для запросов, который помогает избежать дублирования. Например, при повторной отправке платежного запроса сервер проверяет ключ и не создаёт дубль.
Подробнее в подкасте
Idempotency-Key: <unique-key>
◽️ Часовые пояса
Когда система работает в разных регионах, важно учитывать часовые пояса и их можно передавать как обязательные заголовки во всех запросах.
Стандартные названия из моего опыта:
Time-Zone: UTC+3
X-Time-Zone: UTC+3
📌 + помним про Response Headers (заголовки ответов)
Полные подборки стандартных Headers:
Правильно выбранные Headers помогают удобно передавать все системные параметры для обмена данными, которые не важны для бизнес-логики и алгоритмов работы API-методов.
#RestApiGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤22👍8❤🔥1
Шаблон_задачи_на_REST_API_для_Confluece_GetAnalyst.pdf
196 KB
🟢🤖 Шаблон требований к REST API для Confluence + примеры использования 🔖
👉 Ключевое в шаблоне REST API:
✔️ Общее описание
✔️ Доступы
✔️ Ограничения
✔️ Запрос: HTTP-метод, URL, query, headers, body (json)
✔️ Успешный ответ: HTTP-код, headers, body (json)
✔️ Ошибочные ответы: HTTP-код, headers, body (json)
✔️ Требования к реализации - алгоритм
✔️ Маппинг данных (API - БД - Внешние API для интеграций)
👉 Зачем нужен шаблон требований на REST API методы?
1️⃣ Разработчики быстрее ориентируются в задаче
Они понимают, где искать бизнес-логику, параметры запроса, тело запроса, ответы, ошибки, ограничения и примеры.
2️⃣ Постановка задачи сразу становится основой будущей документации
3️⃣ Системный аналитик не упускает требования и всегда держит единую структуру документа.
🤖 Автоматизировать постановку задач на новые методы с помощью кастомизированных AI-агентов
Про это буду рассказывать в следующих постах 🔥
Этих 4-х пунктов достаточно, чтобы понять цель шаблона:
▫️ повысить качество постановок задач и документации
▫️ автоматизировать свою работу с AI
🔖 Примеры требований — выгрузки готовых задач из Confluence по шаблону:
🔗 Cоздание товара - POST /products
🔗 Редактировать товар - PUT /products/{productId}
🔗 Создать мероприятие - POST /events
🔗 Получить рецепт - GET /recipes/{recipeId}
🔗 Получить список книг - GET /books
К посту добавила выгрузку шаблона из Confluence.
Также в нашем блоге можно найти статью с пояснениями к нему.
Забирайте, пользуйтесь 🤝
#ResApiGa
📱 Tg | 💙 ВК | 💬 Max
👉 Ключевое в шаблоне REST API:
✔️ Общее описание
✔️ Доступы
✔️ Ограничения
✔️ Запрос: HTTP-метод, URL, query, headers, body (json)
✔️ Успешный ответ: HTTP-код, headers, body (json)
✔️ Ошибочные ответы: HTTP-код, headers, body (json)
✔️ Требования к реализации - алгоритм
✔️ Маппинг данных (API - БД - Внешние API для интеграций)
👉 Зачем нужен шаблон требований на REST API методы?
1️⃣ Разработчики быстрее ориентируются в задаче
Они понимают, где искать бизнес-логику, параметры запроса, тело запроса, ответы, ошибки, ограничения и примеры.
2️⃣ Постановка задачи сразу становится основой будущей документации
3️⃣ Системный аналитик не упускает требования и всегда держит единую структуру документа.
Про это буду рассказывать в следующих постах 🔥
Этих 4-х пунктов достаточно, чтобы понять цель шаблона:
▫️ повысить качество постановок задач и документации
▫️ автоматизировать свою работу с AI
К посту добавила выгрузку шаблона из Confluence.
Также в нашем блоге можно найти статью с пояснениями к нему.
Забирайте, пользуйтесь 🤝
#ResApiGa
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18❤6👍3
Если вы каждый раз пишете AI:
«работай как системный аналитик»
«вот мой проект»
«вот шаблон требований»
«вот правила REST API»
«оформи результат вот так»
…то вы не используете AI как инструмент.
Вы просто бесконечно переписываетесь с очень быстрым, но плохо управляемым стажёром 😅
👉 Гораздо удобнее один раз настроить переиспользуемого AI-агента под проект:
+ задать правила работы;
+ подготовить системный промпт;
+ загрузить шаблоны и примеры;
+ описать формат результата.
А дальше просто ставить ему задачи в максимально простом виде:
Сделай требования к REST API-методу записи питомца к ветеринару.
и получать не хаотичный текст, а структурированный черновик постановки задачи для разработки.
Я подготовила короткое практическое руководство, где показываю, как настроить такого AI-агента и использовать его как нормальный рабочий инструмент аналитика.
👉 Забрать полное руководство + доп. материалы
🕘 На настройку: 5 минут
🚀 На выходе: черновик требований примерно на 70%+ готовности
AI не заменит сильного аналитика.
Но сильный аналитик с правильно настроенным AI работает быстрее 🤝
#AI_for_analysts #ResApiGa
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥24❤13🦄5