GetAnalyst - Навыки • Системный анализ • Бизнес-анализ
19.6K subscribers
2.09K photos
75 videos
207 files
1.19K links
Разбор задач на проектирование систем 🚀 Канал для системных аналитиков, бизнес-аналитиков, тестировщиков и менеджеров проектов

Админ @getanalyst
Сайт https://getanalyst.ru
Чат t.me/getanalystchat
Начинающим в IT @getanalyststart

РКН №5013005196
Download Telegram
👩‍💻 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
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥39👍188❤‍🔥5
💙 Всё про REST API методы в одной картинке 💙

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

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


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

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

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


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

#RestApiGA
❤‍🔥32👍6🔥51
💻 Когда Системный Аналитик работает с 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
Please open Telegram to view this post
VIEW IN TELEGRAM
❤‍🔥19👍138🔥5🤔1
Дизайн 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
или заполняйте анкету предзаписи на сайте.
Мы поможем оценить ваши текущие навыки, пришлем дополнительную информацию и ответим на все вопросы 🤝
Please open Telegram to view this post
VIEW IN TELEGRAM
👍93
🤖 Полный гид по AI для системных аналитиков: как выбирать нейросети и для каких задач использовать 🤖

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

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

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


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

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


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

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

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


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


Получай самые актуальные знания с GetAnalyst — сообществом, где системные аналитики растут каждый день 📈
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥36👍83
💥 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
🔥6015👍7👌2🤔1
GetAnalyst_REST_API_4_ошибки_при_проектировании.png
443.1 KB
🐞 Виды 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
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2312🔥10
💡 Иногда просто не хватает одного действияи немного вдохновения 💡

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

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


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


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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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


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


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



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

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

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


👉 Если вам нужен знак, что всё возможно — вот он.
Главное быть смелым и открытым миру.
Please open Telegram to view this post
VIEW IN TELEGRAM
47👍16💯5👎4
📌🥗 Новый проект по REST API — Кулинарная платформа #RecipeGA 🥧📌

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


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


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


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


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


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


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

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

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

#RestApiGA
🔥77👍166❤‍🔥1
🥑 Как строить 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
🔥38👍105❤‍🔥4
🤖 Нейросети для проектирования БД и SQL-запросов | Четверг, 19:00 Мск 🤖

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


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

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


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


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

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


👇👇👇
А если вам уже сейчас хочется узнать больше про использование нейросетей для работы, то рекомендую послушать новый подкаст
🎧 Полный гид по AI для системных аналитиков
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔53🤯1