GetAnalyst - Навыки • Системный анализ • Бизнес-анализ

⚡️🐇 RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам 🐇⚡️

Знакомимся с брокером RabbitMQ: как он работает, когда применяется, и чем принципиально отличается от Kafka, чтобы вы могли уверенно выбирать решение под задачи проекта.

🔗 Презентация и шаблон постановки задачи

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

Видео эпизода доступно в:
⏯ RuTube
⏯ YouTube
⏯ VK Video
⏯ Telegram

Аудио-эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Castbox
⏯ Spotify

Подписывайтесь на GetAnalyst, чтобы каждый день получать новый опыт в системном анализе! ⚡️

📍 5 ошибок в дизайне REST API | Открытый вебинар 24 апреля 📍

Аналитики встречаются с REST API постоянно.

И если говорить о создании API-методов "с нуля", то вроде бы всё понятно:
выбирай правильные HTTP методы, делай URL по аналогии, описывай запросы и ответы в JSON.

Но на практике — сплошные нюансы.

Даже опытные аналитики делают ошибки:
➖ добавляют глаголы в URL,
➖ путают уровни иерархии,
➖ описывают JSON, на которые "ворчат" разработчики,
➖ не думают о поддержке и обратной совместимости.
И на собеседованиях — те же грабли 😔


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


🐞 5 ошибок в дизайне REST API:
👉 примеры реальных задач с проектов и собеседований
🗓 24 апреля (чт), 19:00 Мск

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


В результате практики:
+ Получите опыт работы с инструментом Postman.
+ Сделаете рабочую Postman-коллекцию запросов к реальному API для личного портфолио.
+ Будете знать типичные ошибки при дизайне REST API и как их избежать.
+ Получите примеры корректных постановок задач на API-методы.


Этот урок даст вам не только знания, но и рабочие инструменты 💡

Присоединяйтесь онлайн и получайте новый опыт! 🙌

☑️ Проверьте свои знания: как строить эндпоинты для REST API методов ✅

Разобрали:
🔗HTTP-методы
🔗Структура URL
🔗Пагинация

Попробуйте ответить на вопросы, а затем сравнить результаты с предложенными ответами 👇

1. Какой метод и URL использовать для добавления нового продукта с КБЖУ?
❌ POST /createProduct
→ В URL дублируется действие, хотя оно уже обозначено методом POST
✅ POST /products
→ Метод POST = создание, /products — имя сущности (ресурса), которым управляем


2. Какой эндпоинт нужен для создания рецепта конкретным пользователем?
❌ POST /recipes/{userId}
→ Ресурс recipes не вложен внутрь userId, иерархия нарушена
▫️ POST /recipes?userId={userId}
→ Можно, но есть вариант лучше
▫️ POST /users/{userId}/recipes
→ Аналогично
✅ POST /recipes
с авторизацией пользователя в заголовке header запроса
→ Кто автор — понятно из токена, userId не нужен в URL. В двух вариантах выше не лучшее решение, т.к. по факту получается, что есть дублирование id пользователя в запросе


3. Как изменить обложку (фото) рецепта с id = 45?
❌ PUT /recipes/45/changeCover
→ Избыточный глагол в URL, лучше обозначить действие через PATCH
✅ PATCH /recipes/45/cover
→ PATCH подходит для частичного изменения (только обложки). Это конкретный эндпоинт для загрузки нового изображения
✅ PATCH /recipes/45
с телом { "coverUrl": "..." }
→ Если есть отдельный метод POST /images на загрузку изображений в файловое хранилище, из которого можно получить url для подстановки в "coverUrl"


4. Как удалить продукт из справочника?
❌ PATCH /deleteProduct/15
→ Действие должно быть в глаголе HTTP - DELETE
▫️ DELETE /products?productId=15
→ Есть вариант лучше
✅ DELETE /products/15
→ Лучший вариант
✅ PATCH /products/15/archive
→ Если хотим архивировать - удалить с возможностью восстановления


5. Как удалить продукт из рецепта (ингредиент)?
❌ DELETE /products/15
→ Это удалит сам продукт, а не его использование в рецепте
✅ DELETE /recipes/8/ingredients/15
→ Соблюдена иерархия


Какие ещё варианты у вас получились? Есть вопросы? Пишите комментарии 📝👍

#RestApiGA #RecipeGA

💎 Headers в REST API: что это и зачем 💎

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:
🔗 Wikipedia
🔗 MDN


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

#RestApiGA

📑 Элементы пагинации в REST API: что это, когда нужно, примеры 📑

Когда мы работаем со списками в REST API, почти всегда рекомендуется использовать элементы пагинации (pagination).

Элементы пагинации позволяют реализовывать постраничную выдачу данных. Другими словами, разбивать большие объемы данных на маленькие части.

Это нужно, чтобы не загружать с сервера за один запрос весь миллион записей из БД, а делать это порциями. Такое решение экономит трафик.

Ключевые параметры пагинации (допустимы другие названия):

◽️ limit — максимальное количество записей, которые хотим получить в ответе. Query-параметр.
Альт. названия: size.
◽️ offset — смещение, с которого начинается выборка данных. Query-параметр.
Альт. названия: page, cursor.
◽️ count — общее количество записей по запросу. Возвращается в ответе, в body (JSON), вместе со списком, в запросе не передаётся.
Альт. названия: total.


Пример получения списка рецептов в #RecipeGA:

GET https://recipe-ga.com/api/users-app/2.1/recipes

Этот запрос вернет список всех рецептов.

Но что, если в БД сохранено 10 000 рецептов? Получать все за раз?
Кажется, это перебор. Никакой пользователь не будет реально читать весь этот объем данных.
Поэтому лучше получать список по частям.
👉 Вот здесь и пригодятся limit и offset!

Допустим, нужно получать по 12 рецептов за запрос:

🔸 1-й запрос: получить первые 12 рецептов
GET https://recipe-ga.com/api/users-app/2.1/recipes?limit=12&offset=0

🔸 2-й запрос: еще 12 рецептов
GET https://recipe-ga.com/api/users-app/2.1/recipes?limit=12&offset=12

🔸3-й запрос: еще 12 рецептов
GET https://recipe-ga.com/api/users-app/2.1/recipes?limit=12&offset=24

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


👉 Зачем это нужно?
1. Удобство отображения: Не все данные нужно отображать сразу, особенно если их очень много.
2. Оптимизация: Запросы с меньшим количеством данных обрабатываются быстрее и требуют меньше ресурсов.


Запоминаем и пользуемся, почти по всех API есть пагинация 🙂

#RestApiGA

🤖 Нейросети для проектирования БД и SQL-запросов | Четверг, 19:00 Мск 🤖

В этот четверг будем на практике разбираться, как эффективно использовать нейросети для проектирования БД и выполнения SQL-запросов.


🟢 Использование ChatGPT (и не только) для проектирования БД
🗓 17 апреля, чт
🕘 19:00 - 21:30 МСК
🔗 Подробности и запись


В результате практикума:
✔️ Научитесь грамотно формулировать промпты для AI.
✔️ Получите связки инструментов, которые необходимы аналитикам для работы с базами данных.
✔️ Создадите свою СУБД через DBeaver и выполните SQL-запросы в ней.


✅ Запись будет доступна после занятия.
✅ Для всех участников сейчас доступно занятие в записи по SQL-запросам с практикой в реальной БД 😎

По вопросам можно писать через сайт или @getanalyst 💬


👇👇👇
А если вам уже сейчас хочется узнать больше про использование нейросетей для работы, то рекомендую послушать новый подкаст
🎧 Полный гид по AI для системных аналитиков

🥑 Как строить URL для REST API методов: разбираем на практике 🥑


Рекомендуемая маска:

<Вид метода HTTP>

<Протокол>

://

<Доменное имя>

/ api

/ <имя API> /

<версия>

/ <путь: названия сущностей и path-параметры> ?

<query-параметры>

✅ Метод HTTP
Не относится к URL, но тесно связан с ним. Правила выбора в этом посте.

✅ Протокол
В начале любого URL указывается протокол HTTP(s).

✅ Доменное имя
Основной адрес, по которому можно обращаться к серверу.

✅ Путь (Path)
Включает в себя один или несколько сегментов, разделённых слешами (/):

▫️“api” - указатель на каталог API сервера, может быть название вида api.
▫️имя API - указывает на конкретный интерфейс API, предназначенный для разных пользователей системы.
▫️v1 - версия API, важна для поддержки совместимости с предыдущими версиями.

В этой части может быть организована иерархия связанная с вложенными сущностями или действиями над объектами:
▫️recipes - это ресурс, к которому осуществляется доступ. В данном случае “рейепт”. Может быть в единственном числе (recipe).
▫️{recipeId} - это параметр в пути URL (path-параметр), указывающий на конкретный рецепт по его id в БД системы. Фигурные скобки {} обозначают переменную часть URL, значение которой должно быть предоставлено клиентом (например, идентификатор 18290).



✅ Query-параметры (Query-parameters)
Дополнительные параметры запроса после ?, необязательны. Если их несколько, то перечисление через символ &.
Обычно используются для фильтров, сортировок и пагинации при получении списков методом GET, но могут быть и в других методах.

В примере:
GET …/recipes?offset=0&limit=20&name=пирог&authorId=777
👉 ?offset=0&limit=20 - запрос результатов с 0-го, ограниченный 20-ю на страницу. Это два отдельных query-параметра - элементы пагинации (постраничного получения данных).
👉 name и authorId - фильтры по названию и id автора рецепта.


Больше примеров на картинках 🖼


Благодаря такой структуре всегда понятно, каким ресурсом (сущностью) управляет REST API метод ✅

#RestApiGA #RecipeGA

📌🥗 Новый проект по REST API — Кулинарная платформа #RecipeGA 🥧📌

Мы продолжаем изучение навыков системных аналитиков на практике. В этом месяце погружаемся в тему проектирования REST API для кулинарного проекта 🥧


RecipeGA — это веб- и мобильные приложения, в которых пользователи создают и делятся рецептами с фотографиями и составом блюд на основе заранее добавленных продуктов с КБЖУ (калории, белки, жиры, углеводы).


Возможности пользователей платформы:
1. Регистрация в системе
2. Создание продуктов с указанием КБЖУ
3. Добавление рецептов, включающих:
+ название блюда,
+ описание блюда,
+ ингредиенты,
+ рецепт / инструкция по приготовлению,
+ основная и дополнительные фотографии.
Продукты для рецептов они могут как создавать сами, так и брать уже готовые, из справочника, ранее созданные другими пользователями.


👉 Основной контекст для работы: управление продуктами и рецептами.


👉 Наши задачи по проектированию REST API методов, которые будут использоваться в мобильных и веб-приложениях:
▫️ Сделать с нуля методы GET, POST, PATCH, DELETE для продуктов и рецептов
▫️ Проработать структуру JSON для запросов и ответов
▫️ Разобрать пример постановки задачи на разработчиков
▫️ Сформировать корпоративный стандарт по дизайну REST API для проекта
▫️ Разобраться с документированием API через Postman и Swagger (OpenAPI)


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


Проект объявляю открытым! 🎉

Чтобы участвовать, включайте уведомления, следите за публикациями в канале с тегом #RecipeGA, и задавайте вопросы в комментариях к постам! Разбирайтесь, изучайте и получайте новый опыт!

Будет вкусно и полезно! 😉🥙

#RestApiGA

💡 Иногда просто не хватает одного действия… и немного вдохновения 💡

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

🤝 А ещё они показывают, насколько важно быть открытым к переменам и ценить силу хорошего нетворкинга.

#1. Иногда, чтобы изменить свою жизнь, нужно просто помнить чей-то заказ

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

Однажды зашёл яркий мужчина и заказал крайне сложный, кастомный смузи — из серии “вот это, но без этого, и добавьте щепотку вот этого, но только если...”.
Необычный рецепт она запомнила, да и самого мужчину тоже.

Когда он пришёл в следующий раз, она повторила заказ по памяти прежде чем он успел что-то сказать.
Он был в шоке и спросил “Кто ты?!” 😂
Завязался разговор.

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

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

Она — вообще ни разу не айтишник. Просто быстро схватывает.

Сначала она думала: "Зачем мне это, я же просто делаю смузи, что я там буду делать без знаний?".
Но в итоге согласилась.

Сейчас она системный аналитик. Обожает свою работу. Обсуждали с ней подходы к написанию требований и процессы работы её команды. Толковый специалист.

И да, всё это началось с одного нестандартного заказа 🍹

#2. Бухгалтерия устала

Больше 8 лет она считала чужие налоги. Гибридная работа: в офисе и дома. Но постоянный стресс. Сроки. Отчетность. Куча нудных цифр.

Все повышения получены. Драйва в работе больше нет. Неинтересно, некуда расти.

Можно было сменить фирму и вырасти в деньгах. Но что изменилось бы? Радости к работе это бы не добавило.

Она решила попробовать себя в IT.
Только начала учебу, но что-то пошло не по плану.
Почти сразу после начала обучения она получила оффер в IT-компанию 🙃

Не магия, а совпадение. Её знакомый работает в ТОП-овой компании, которая делает ПО для ведения бухгалтерии. Им как раз был нужен кто-то из отрасли, кто понимает боль клиентов и может помочь им развивать продукт.

Когда он узнал, что она хочет в IT, то… На собеседование она попала быстро.

Теперь она бизнес-аналитик — часть продуктовой команды.
Полгода в новой должности. Радость от новых знаний.
Кайф от жизни и уверенность, что рост есть.


А ещё …

# Из отвечающего за бумажки в гос конторе до БА, с возможностью роста в СА.

# Из учителя в школе до СА.

Разные истории.
Разные люди, разные старты, разные решения.

👉 А суть такова: перемены — это не страшно, а вселенная всегда помогает нам.

Иногда всё, что нужно — вдохновение и первый шаг.
А дальше начнёт складываться.


👉 Если вам нужен знак, что всё возможно — вот он.
Главное быть смелым и открытым миру.

🐞 Виды HTTP-методов: не повторяйте эти ошибки 🐞

GET, POST, PUT, PATCH и DELETE - виды методов, часть протокола HTTP.
Нужны, чтобы стандартизировать взаимодействие между клиентом и сервером.

Каждый метод выполняет определённое действие и соответствует логике CRUD-модели (Create, Read, Update, Delete).


Основные HTTP-методы, которые нужно знать при проектировании REST API 👇


✅ POST: создание нового ресурса
Добавить новый товар в Интернет-магазин
Зарегистрировать пользователя
Создать заказ товаров
👉 Иногда POST может использоваться для получения данных:
+ асинхронные запросы
+ слишком много query-параметров (фильтров) для списков


✅ GET: получение ресурсов
Посмотреть список товаров
Получить информацию о выбранном товаре
Проверить статус заказа


✅ PUT: обновление ресурса целиком или создание нового
для полной замены данных ресурса

Вызываем PUT (изменить/создать) для товара со штрихкодом 0123456789, на вход передаём все-все данные о нём:
👉 если товар с таким штрихкодом уже был создан, то обновить данные по нему в БД целиком, даже если какие-то параметры, как название или стоимость менять сейчас не нужно
👉 если товар с таким штрихкодом еще не создан, то создать новый

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



✅ PATCH: частичное обновление ресурса
для обновления только некоторых полей ресурса - частичное редактирование.
Изменить описание товара и передать на вход методу только его.
При этом действии в БД поменяется только описание товара, и не будет полной перезаписи всех полей, как это происходит при использовании PUT.


✅ DELETE — удаление ресурса
Удалить выбранный товар из магазина
Удалить выбранный товар из заказа


🐞 Распространенные ошибки при выборе HTTP-методов для REST API на картинке к посту


Правильное использование HTTP-методов в REST API упрощает взаимодействие с вашей системой, так как делает API предсказуемым и удобным для разработчиков.

#RestApiGA

💥 12 важных терминов по API,
которые нужно знать системным аналитикам 💥

1. API (Application Programming Interface)
2. REST API (Representational State Transfer)
3. HTTP-методы запросов
4. Эндпоинты
5. Коды ответов
6. Ограничение частоты запросов (Rate Limiting)
7. Полезная нагрузка (Payload)
8. Заголовки (Headers)
9. Аутентификация
10. Авторизация
11. Пагинация
12. Кэширование


Дополнительно:
1. OAuth
2. JWT Token
3. API Gateway
4. API Keys
5. Basic Authentication
6. Bearer Tokens
7. CORS
8. Webhooks
9. OpenAPI
10. API Versioning (Версионирование API)
11. Content Negotiation
12. Query Parameters
13. Path Parameters
14. API Documentation
15. API Monitoring
16. Throttling
17. Circuit Breaker
18. Idempotency (Идемпотентность)
19. API Proxy
20. Retry Logic (Логика ретраев / повторов)
21. Batch Processing (Пакетная обработка)
22. API Security
23. Health Checks
24. API Testing
25. Mock APIs
26. API Marketplace
27. API Schema
28. Semantic Versioning (Семантическое версионирование)
29. Hypermedia
30. API Deprecation (Устаревание API)

Вроде бы всё самое важное и нужное на месте 😎

#RestApiGA

🤖 Полный гид по AI для системных аналитиков: как выбирать нейросети и для каких задач использовать 🤖

В новом эпизоде подкаста GetAnalyst вы найдёте обзор основных AI-инструментов для системных аналитиков. Разберётесь, чем они отличаются, какие возможности предлагают, что и для каких задач подходит лучше всего.

Ключевые нейросети в обзоре:
🤖 ChatGPT
🤖 DeepSeek
🤖 Gemini
🤖 YandexGPT

Также расскажем про дополнительные инструменты со встроенными AI-возможностями и про вспомогательное ПО, которое помогает системным аналитикам использовать нейросети с максимальной пользой.


Здесь мы даём готовые инструкции, как системный аналитик может применять нейросети на практике, чтобы оставаться конкурентоспособным в быстро меняющемся мире IT.

🔗 Статья к эпизоду с дополнительными материалами


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

👉 Реальные кейсы, примеры и личный опыт.

Подкаст, который точно стоит послушать сегодня!


Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video


Получай самые актуальные знания с GetAnalyst — сообществом, где системные аналитики растут каждый день 📈

✨ Дизайн REST API с 6 мая - открыта запись в новый поток практической программы ✨

Если вы недавно интересовались актуальными требованиями к Системным аналитикам, то наверняка видели:

+ Знание REST API / JSON
+ Опыт проектирования и документирования API
+ Понимание принципов работы мобильных приложений
+ Знание OpenAPI / Swagger для создания REST API документации
+ Навык тестирования API Backend (Postman)

Все эти навыки, в разных формулировках, ожидают от Middle и Senior Системных аналитиков, которым предстоит работать с Backend- или мобильными командами, в проектах с интеграциями.


Мы осваиваем их в рамках одного большого проекта, на практической программе:

💻 Дизайн REST API
🗓 Старт 6 мая 2025
✅ Первая онлайн-встреча: 13 мая

🔗 Узнать подробности и записаться

В ходе работы учимся проектировать методы REST API с нуля, глядя на требования, архитектуру, БД и дизайн UI/UX системы.

Проект с подвохами и сложностями, на котором “набиваем шишки”, учимся писать с нуля и структурировать API-документацию, осваиваем ключевые инструменты СА 🛠



В результате вы создаете свой проект API-документации в Postman и умеете запустить работающие REST API методы Backend на заглушках, даже без навыков программирования! 🤩

👉 Это самая весомая и “программистская” часть вашего профессионального портфолио.



🎁 По заявкам до 22 апреля дарим дополнительное обучение по БД+SQL в подарок + самые выгодные условия.


Есть вопросы?
Пишите @getanalyst,
на почту info@getanalyst.ru
или заполняйте анкету предзаписи на сайте.
Мы поможем оценить ваши текущие навыки, пришлем дополнительную информацию и ответим на все вопросы 🤝

💻 Когда Системный Аналитик работает с REST API 💻

Глядя в вакансиях Системных Аналитиков на ключевые слова "REST API", полезно понимать, что может за этим скрываться.

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


👉 1. При создании новой функциональности
У вас в команде Frontend + Backend разрабатываются отдельно - разные кодовые базы.
Frontend / Мобильные приложения взаимодействуют с Backend по REST API.

Когда в системе нужно добавить новую функциональность, то от аналитика ожидают, что он может:

+ со стороны Backend - проектировать REST API:
▫️ Определить REST API методы, которые нужно разработать для работы Frontend.
▫️ Описать алгоритмы их работы, которые будут программировать разработчики.
▫️ Продумать требования к обработке ошибок.
▫️ Сделать ролевую модель доступов к REST API методам.
▫️ Спроектировать структуру API-методов:
+ на естественном языке описать входные параметры запроса и параметры ответа на запрос.
+ продумывать техническую реализацию и описывать сразу тип метода (GET, POST, ...), endpoint (URL), query-параметры, headers запроса и ответа, тело JSON запроса и ответа, статус-код ответа.
▫️ Описывать маппинги (сопоставление) данных между БД и параметрами API-методов (в URL, JSON).
▫️ Формировать техническую API-документацию, которую в дальнейшем будут использовать разработчики: в Postman, Confluence или Swagger (OpenAPI).

+ со стороны Frontend - подключение разработанного на Backend REST API метода:
▫️ Читать техническую REST API-документацию.
▫️ Проверять работу готовых REST API методов через Postman, чтобы убедиться, что все работает так, как описано в документации.
▫️ Описывать маппинги (сопоставление) данных между UI и параметрами API-методов (в URL, JSON).


👉 2. Интеграции внешние - подключение сторонних систем по REST API
Состав подзадач аналогичен подключению API на Frontend.
Отличия:
1. Работа ведется не с внутренней API-документацией, а с чужой - на внешние системы.
2. Интеграции - это обычно про взаимодействие Backend-ов. Алгоритм работы может включать одновременно несколько компонентов: наш Frontend, наш Backend (+БД), внешний Backend.
3. Всвязи с этим больше таблиц маппингов данных в постановках задач:
✔️ Маппинг 1: UI + наш REST API,
✔️ Маппинг 2: наш REST API + внешний REST API + наша БД.


👉2.1. Интеграции - создание интеграционных REST API-методов (дополнительно к п. 2)
Нужно сделать REST API-метод на Backend, который будет вызывать любой API внешней системы (хоть REST, хоть SOAP, хоть GraphQL).
Состав подзадач аналогичен проектированию API-методов на Backend.

Маппиг данных теперь будет не только для БД и параметрами нашего API-метода (в URL, JSON). К нему добавятся еще и параметры внешней системы, которые могут быть в любом формате в зависимости от вида API.


👉 3. Интеграции внутренние - обмен данными между сервисами и микросервисами по REST API
Состав подзадач аналогичен подключению API на Frontend, но больше компонентов в описании алгоритмов и таблиц маппингов.


👉 4. Для анализа ошибок работы ПО
Что-то пошло не так при работе Frontend (или мобильного приложения)?
Открываем консоль.
Анализируем запросы и ответы REST API методов.
Тестируем сложные ситуации через Postman, смотрим на результаты и ищем причины ошибок.



Рекомендация:
Для Системного аналитика важно понимать REST API не только с точки зрения возможностей, но и с точки зрения ограничений, типовых проблем и ошибок в проектировании.
Чем лучше вы их понимаете, тем качественнее будет работать ПО разработанное по вашим требованиям.


#RestApiGA

💙 Всё про REST API методы в одной картинке 💙

Публикую для вас картинку-шпаргалку, которую можно использовать при проектировании методов REST API и постановке задач на Backend-разработчиков 🙌

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


👉 А чтобы вы наглядно могли сопоставить структуру методов на картинке с реальными REST API, предлагаю вам посмотреть примеры открытой API-документации для интеграции с крупными сервисами:

ТБанк - Кредитные продукты
Jira - работа с задачами

Проверьте себя!
Это отличная практика по изучению структуры методов REST API.
Сможете ли найти все описанные на картинке параметры в документации?


Дополнительно предлагаю посмотреть статью про связь REST API и протокола HTTP, чтобы после этой практики закрепить, почему REST API это именно архитектурный стиль основанный на протоколе HTTP.

#RestApiGA

👩‍💻 6 главных принципов REST API, про которые спрашивают на собеседованиях 👩‍💻

REST API — архитектурный стиль для создания веб-сервисов, основанный на протоколе HTTP.

REST API основан на протоколе HTTP:

это означает, что все принципы работы HTTP методов, их структура запросов и ответов, будут также применимы и для REST API.

Пример:
+ в HTTP есть виды методов: GET, POST, PUT, PATCH и т.д.
+ в REST API методы абсолютно те же.


Архитектурный стиль REST добавляет к HTTP дополнительные правила и принципы, по которым должен происходить обмен данными👇

Главные принципы REST:
1. Строгое разделение клиента и сервера
2. Единый интерфейс
3. Без сохранения состояния (Stateless)
4. Многоуровневая система
5. Кэширование
6. Выполнение кода по запросу

В картинках к посту просто и с примерами разобрала эти принципы.

Это не самая ценная в работе информация, но перечень этих принципов и их понимание могут спрашивать на собеседованиях 👌

#RestApiGA