🧩 22 декабря | Маппинг данных: БД и JSON 🧩

Если вы хоть раз описывали интеграцию или требования к REST API-методу, то возможно вам знакомо:
- в БД одно, в JSON другое, а на UI третье,
- «а почему поле так называется»,
- «а откуда берём значение»,
- «а что если null»,
- «а как это маппить в требованиях».


Чтобы закрыть эти вопросы раз и навсегда и уверенно чувствовать себя в связке JSON ↔ БД, приглашаю вас на онлайн-практикум 👇

🧩 Маппинг данных: БД и JSON
🗓 22 декабря, 19:00 Мск

👉 Записаться на практикум
Стоимость участия от 1390 рублей


✅ Запись будет опубликована в платформе на следующий день после занятия
🎁 Занятие в записи по использованию AI для проектирования БД + SQL


План:
1. Знакомство с JSON
2. Практика формирования JSON для API методов на основе БД и дизайна UI
3. Описание маппингов данных
4. Автоматизация задачи с использованием AI-инструментов


В результате практикума вы:
✔️ Поймёте, как связать UI → JSON → БД в одну логичную схему
✔️ Заберёте себе понятный подход, как оформлять маппинг в требованиях
✔️ Получите практический опыт, который можно сразу применять в работе


По вопросам можно написать @getanalyst или info@getanalyst.ru.


До встречи онлайн! 🤩

🔑 Ключевые параметры OAuth 2.0 🔑

Прежде чем разбирать OAuth 2.0 flows (grant types) - алгоритмы, давайте познакомимся с его ключевыми параметрами.


📌 Шаги в OAuth 2.0

👉 Запрос на авторизацию - получение code

GET .../oauth/authorize
?response_type=code
&client_id=...
&redirect_uri=...
&scope=...
&state=...

👉 Callback на ваш redirect_uri - получен code

GET https:// testapp .com/api/v1/auth/oauth/provider/callback
?code=/...
&state=...

👉 Обмен code на токены

POST .../oauth/token

grant_type=authorization_code&
code=...&
client_id=...&
client_secret=...&
redirect_uri=...

📌 Параметры:

1️⃣ response_type
Тип результата, который вы хотите получить на шаге авторизации - регулирует ответ на GET /authorize

Где используется:
В URL для GET /authorize


2️⃣ client_id
Публичный идентификатор приложения, который предоставляет провайдер OAuth 2.0 (Mail ru /Google и др) после его регистрации у себя.

Где используется:
+ в URL для GET /authorize
+ в теле POST /token
+ иногда в запросах на обновление токена или в других grant types


3️⃣ client_secret
Cекрет (пароль) вашего приложения, который предоставляет провайдер OAuth 2.0 после регистрации

Где используется:
чаще всего в POST /token


4️⃣ redirect_uri
Это URL, куда провайдер OAuth 2.0 возвращает пользователя после аутентификации

Пример:
Пользователь вводит логин и пароль от своего Google-аккаунта на безопасной форме от Google. После этого Google делает переход на redirect_uri

Кто формирует:
Владелец приложения, который будет использовать OAuth 2.0.
Он указывает его в настройках при регистрации.

Где используется:
+ в URL для GET /authorize
+ в теле POST /token


5️⃣ scope
Список прав/доступов, которые вы запрашиваете у пользователя.

Пример:
Ваше приложение запрашивает у пользователя доступ к его Google-аккаунту:
+ ФИО
+ почта
+ Google-диск, чтение
и др.

scope=profile,email,drive:read

Кто формирует:
Владелец приложения

Где используется:
В URL для GET /authorize

На что влияет:
+ какие данные/действия разрешены для access_token
+ что пользователь увидит в окне согласия на безопасной форме от провайдера OAuth


6️⃣ state
Случайная строка для защиты от подмены (CSRF атаки) и для связывания “запрос-ответ”

Кто формирует/проверяет:
Backend приложения, который использует OAuth 2.0

Где используется:
+ отправляется в URL для GET /authorize
+ возвращается провайдером в redirect_uri вместе с code или error

Backend генерирует state, сохраняет (в сессии/БД/кэше), потом сравнивает с ответами от OAuth 2.0 провайдера

Если state не совпал — считаем запрос из процесса авторизации атакой/ошибкой и прерываем его


7️⃣ code (authorization code)
Временный одноразовый код, который провайдер возвращает после успешного входа пользователя.

Он нужен, чтобы безопасно обменять его на токены (access/refresh) через POST /token

Где появляется:
В URL на вашем redirect_uri (callback) после логина.

🕘 Есть срок жизни:
Обычно короткий (минуты/часы)


8️⃣ access_token
Токен доступа к API провайдера (Resource Server).

Где появляется:
В ответе на POST /token.

Как используется:
В дальнейших запросах к API провайдера (Resource Server).

Пример:
Подписываем запрос на получение файлов с Google-диска пользователя с access_token.

🕘 Есть срок жизни:
Обычно короткий (минуты/часы)


9️⃣ refresh_token
Это “токен обновления”.

По нему можно получить новый access_token без повторного запроса логина+пароля у пользователя.

Где появляется:
В ответе на POST /token.
Но не всегда выдаётся провайдером и не всегда нужен.

Как используется:
в запросе POST /token с grant_type=refresh_token.

🕘 Есть срок жизни:
либо нет, либо длинный (месяцы/год)


🔟 token_type
Тип токена.
Чаще всего Bearer.

Где появляется:
В ответе на POST /token


1️⃣1️⃣ expires_in
Срок жизни access_token в секундах.

Где появляется:
в ответе POST /token

Как используется:
+ ваше приложение рассчитывает момент истечения: expiresAt = now + expires_in
+ когда время подходит, то приложение обновляет access_token через refresh_token (фоново) или заново ведёт пользователя на авторизацию

#ИнтеграцииGA
#FoodDeliveryGA_oauth

🔔✅ Сегодня в 19:00 Мск | Маппинг данных: БД и JSON ✅🔔

Онлайн-практикум для системных и бизнес-аналитиков, которые хотят научиться самостоятельно проектировать и описывать JSON-объекты с нуля.

Этот навык даст вам уверенность
+ в рабочих задачах на API и интеграции,
+ в общении с разработчиками,
+ а также на собеседованиях при решении задач на REST API и понимание БД/SQL.

👉 Что получите:
1. Структурированные знания о JSON и его связи с БД+UI
2. Опыт проектирования JSON с нуля под реальные API-методы
3. Опыт разработки маппингов для интеграций Frontend-Backend-Внешние системы
4. Понимание, как применять AI-инструменты


📚 Материалы, которые заберёте:
✔️ Руководство по JSON
✔️ Подборка шаблонов для описания маппинга
✔️ Подборка примеров постановок задач с маппингом
✔️ Оптимизированный промпт для работы с AI + разбор его настроек


📹 Можно посмотреть в записи - будет доступна на следующий день после эфира

🎁 Занятие в записи по использованию AI для проектирования БД + SQL


🧩 Маппинг данных: БД и JSON
🗓 22 декабря, 19:00 Мск

🔗 Записаться на практикум
Стоимость участия от 1390 рублей


По вопросам можно написать @getanalyst или info@getanalyst.ru.

До встречи онлайн! 😌

🔥 Postman: подборка практических руководств по исследованию API 🔥

Документация ≠ реальность.

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

Он заранее подстраховывает разработчиков, уточняя нюансы, которых нет в API-документации внешней системы.


Что важно проверить аналитику для интеграции:
✅ Как работает аутентификация в API
✅ Успешную работу всех API-методов
✅ Протестировать ошибки (при авторизации, отсутствии данных и другие), чтобы понять, как внешняя система реагирует на нештатные ситуации


Делюсь с вами практическими руководствами по исследованию API внешних систем через Postman:

📹 Postman: навык тестирования REST API за вечер

📚 Тестирование API DaData

📚 Тестирование API Unisender

📚 Тестирование API банка ВТБ

📚 Тестирование API KudaGo и DashaMail

📚 Тестирование API ChatGPT

👉 В этих руководствах всё четко, с картинками и по шагам.

С ними вы сможете освоить Postman за выходные, и сразу же пополните своё портфолио несколькими коллекциями запросов 🙌


🔖 Сохраняйте пост в избранное,
чтобы пройти все руководства и получить реальный опыт для работы с задачами на интеграции


#ИнтеграцииGA

🎄 [27-30 декабря] Открытый интенсив по REST, GraphQL и gRPC с практикой в Postman 🎄

Cегодня всё реже бывает “только REST”.
В одном продукте REST остаётся публичным API, в другом GraphQL нужен, чтобы не таскать лишние поля в мобильные приложения, а внутри микросервисов всё чаще живёт быстрый gRPC.


Чтобы передать вам практический опыт работы с современными API и интеграциями, мы готовим для вас предпразничный интенсив:

⚡️ Интеграции по REST, GraphQL и gRPC через Postman

🗓 Доступ к записи: 27 - 30 Декабря
🕗 Время на обучение: 4 часа
(можно пройти в своём темпе, в удобное время)

🔗 Регистрация и подробности


Ваши результаты:
✅ Поймёте что такое интеграции и как с ними работать.
✅ Получите уверенную базу знаний по REST API, GraphQL и gRPC, и понимание, как её применить в работе аналитика.
✅ Научитесь читать любую API-документацию и быстро “раскладывать” методы по структуре.
✅ Освоите инструмент тестирования API - Postman.
✅ Получите практический опыт: сможете сами прогнать запросы и проверить ответы REST/GraphQL/gRPC по шагам.


Для кого
🟢 Системные аналитики, которым надо уверенно вести интеграционные задачи
🟢 Бизнес-аналитики, которые хотят понимать “под капотом” и формулировать сильные требования
🟢 Те, кто готовится к собеседованиям (REST/интеграции - база, GraphQL/gRPC - жирный плюс)


Эта практика - ваша возможность сделать огромный шаг в понимании работы с API и интеграциями.

Регистрируйтесь и входите в новый год с новыми навыками и сильными целями! 🎄🚀

------

👉 Интенсив проводится в поддержку практической программы Интеграции систем.

23 декабря завершается запись с лучшей ценой и с бонусным обучением по БД и SQL в подарок.

⚠️ С 2026 года в GetAnalyst планируется повышение цен на все программы, поэтому до 30 декабря — самый выгодный период для записи на обучение

🎄🦩 [Доступ открыт] Интенсив по REST, GraphQL и gRPC с практикой в Postman 🟠


🗓 Только до 30 Декабря
🕗 Время на обучение: 4 часа
(можно пройти в своём темпе, в удобное время)

План:
1. Интеграции: порядок работы над задачами + “как не забыть важное”
2. REST API: методы, статусы, ошибки + практика в Postman
3. GraphQL: query/mutation, типовые ловушки + практика в Postman
4. gRPC: protobuf, способы получения данных + практика в Postman
5. Порядок изучения новых API


🔗 Регистрация и подробности
Если уже регистрировались, ссылка с доступом у вас на почте 📩


Лучший подарок себе на начало 2026 — не мотивация, а новый сильный навык. Обещаем, что на этом интенсиве вы его точно заберёте! 🎄🤝

Регистрируйтесь, практикуйтесь, и пусть новый год начнётся с уверенного «я могу» 🙌🚀

📚 Что такое Grant Type в OAuth 2.0 и на что он влияет 📚

OAuth 2.0 — это стандарт (фреймворк) авторизации.

Grant Type — это выбранный сценарий в OAuth 2.0 (тип потока - flow), который определяет как именно клиент получает токены.


Чтобы помочь вам разобраться как работает OAuth 2.0 и структурировать знания по его flow (алгоритмам), собрала для вас мини-книгу с разбором ключевых Grant Type.


Что внутри:

✅ что такое OAuth 2.0 и наглядные примеры использования в реальных сервисах

✅ Разборы ключевых grant types:
Authorization Code (+ PKCE), Client Credentials (сервис↔сервис),Refresh Token (продление доступа) и другие

✅ Понятные схемы работы OAuth 2.0 в зависимости от grant type


Изучайте и сохраняйте в избранное 🔖
Пригодится для интеграций с Госуслугами и подобными OAuth 2.0 внешними сервисами для входа в вашу систему.


#ИнтеграцииGA
#FoodDeliveryGA_oauth

👩‍💻 Чем отличается API-ключ от токена? 👩‍💻

Это вопрос “с подвохом” для собеседований, в котором СА может запутаться и сказать, что это про одно и то же.

Но разница принципиальная — по смыслу, по рискам, по архитектуре.


🔑 API-ключ (API-key)

API-ключ — это неизменяемый секрет, который идентифицирует приложение/клиента и даёт доступ к API по заранее заданным правилам.

Выдаётся разово и чаще всего не обновляется в течение всего времени жизни интеграции.

Ключевое:

+ обычно не имеет ограничения по сроку жизни или живёт очень долго (годами), пока его не перевыпустят/не отзовут

+ обычно привязан к проекту/приложению, а не к пользователю

+ сам по себе редко несёт “права” внутри, права чаще задаются настройками на стороне сервиса

+ отлично подходит для межсистемных интеграций, где не нужно знать о пользователе

+ используется в header и в query-параметрах

Пример использования в header:

GET /v1/orders

headers:

X-API-Key: 9f3a...a12

Пример использования в query-параметре (хуже по безопасности):

GET /v1/orders?api_key=9f3a...a12

Когда используют API-ключ:
✅ простые интеграции backend → внешний сервис
✅ технический доступ для серверов/скриптов

Пример:
Яндекс.Погода

⚠️ Минус: ключ часто живёт долго.
Утёк ключ - утекла учётка и её надо блокировать / создавать новую / перевыпускать постоянный ключ.
Это может требовать внешнтатное обновление системы - чтобы обновить ключ.



🎫 Токен (Token)

Токен — это временный пропуск (credential), который подтверждает право доступа на ограниченное время и часто с ограниченным набором прав (scopes/claims).

По сути это тоже секрет как и API-key, но он имеет ограниченный срок жизни и другие ограничения.

Если API-key выдают для системы/приложения сразу и его надо использовать в прямом виде, то в случае с токеном для приложения обычно выдают логин и пароль, которые оно должно обменивать на токен через отдельный эндпоинт:

POST /token

Каждый раз когда токен устаревает, надо заново обменивать логин и пароль на токен отдельным запросом:

POST /token

Ключевое:

+ обычно имеет ограниченный срок жизни (минуты/часы)

+ может быть выдан как для пользователя, так и для приложения

+ часто выдаётся после вызова отдельного эндпоинта для обмена логина+пароля на токен (например, в OAuth 2.0, также делают аналогичные эндпоинты и без OAuth 2.0)

+ может быть JWT (со “встроенными” правами), Bearer или просто строка.


Пример использования в запросах после авторизации (Bearer token):

GET /v1/orders

headers:
Authorization: Bearer eyJhbGciOi...

Когда используют токены:
✅ OAuth 2.0 / SSO: Войти через Google / Mail.ru / Госуслуги
✅ доступ к данным пользователя (email, профиль, диск, календарь)
✅ микросервисы/enterprise, где нужен короткоживущий доступ и строгие политики доступа

Пример:
FoodDeliveryGA с OAuth 2.0, где получение токена идёт по одному из авторизационных flow

⚠️ Даже если токен утёк, то его можно перевыпустить в штатном режиме с минимальными рисками. Так как перевыпуск токена каждый час (или другой промежуток времени) уже заложены в стандартном алгоритме работы.


👉 Итого, главные отличия
🔑 API-ключ = постоянный пропуск (пароль) для приложения
🎫 Токен = временный пропуск (пароль) для приложения / пользователя с ограничениями по правам доступа


#ИнтеграцииGA
#FoodDeliveryGA_oauth