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

💜 10 элементов URL в REST API: чек-лист с примерами 💜

Пример - редактировать карточку питомца:
PUT https://vetcare.com/api/public/v1/pets/{petId}

1️⃣ Метод HTTP
GET, POST, PUT, PATCH, DELETE
Не относится к URL, но связан с ним, т.к. вместе образуют эндпоинт.
Подробнее тут

2️⃣ Протокол
Для REST API всегда HTTP / HTTPs

3️⃣ Доменное имя
Основной адрес, по которому можно обращаться к серверу с API-приложением (backend)

Путь (Path)
Включает в себя один или несколько сегментов, разделённых слешами (/):
4️⃣ api - указатель на каталог API сервера, может быть в доменном имени
5️⃣ имя API (public) - указывает на конкретный интерфейс API, предназначенный для разных пользователей системы, либо для разных микросервисов
6️⃣ v1 - версия API, важна для поддержки совместимости с предыдущими версиями

Эндпоинт:
7️⃣ pets - это ресурс, к которому осуществляется доступ. В данном случае “питомец”. Может быть в единственном числе (pet)
8️⃣ {petId} - это параметр в пути URL (path-параметр), указывающий на конкретного питомца по его id в БД системы. Фигурные скобки {} обозначают переменную часть URL, значение которой должно быть предоставлено (например, идентификатор 126734)

+ 9️⃣ Иерархия с вложенными сущностями/действия над объектами
Примеры:
GET ../orders/(id}/payments - получить платеж(и) по заказу
PATCH ../users/(id}/block - заблокировать пользователя


+ 🔟 Query-параметры
Это дополнительные параметры после ?.
Они не являются обязательной частью URL.
Если параметров несколько, они перечисляются через символ &.
Обычно query-параметры используют для фильтрации, сортировки и пагинации при получении списков методом GET, но могут быть и в других методах.

Пример - список ветеринаров:
GET …/vets?offset=0&limit=10&name=Иванов
👉 offset=0&limit=10 - запрос результатов с 0-го, 10 элементов на страницу. Это два отдельных query-параметра - элементы пагинации (постраничного получения данных)
👉 name - фильтр по имени ветеринара



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


К посту прикрепила наглядный практический гайд с дополнительными примерами — забирайте себе как шпаргалку для работы и собеседований 📚🔖

#RestApiGA #VetCareGA

📱 Tg | 💙 ВК | 💬 Max

🎲 Тест с подвохами по REST API и GraphQL: проверь себя за 3 минуты 🎲

REST API кажется простым ровно до того момента, пока не нужно спроектировать эндпоинты для новой системы с нуля.


Готовы "поймать грабли"? 🙈

Собрала для вас 4 вопроса с подвохом по проектированию API, которые будем разбирать на примере проекта #VetCareGA.

Проверим, насколько уверенно вы ориентируетесь в:
✔️ REST API и GraphQL
✔️ URL и эндпоинтах


Подсказки:
📚 Шпаргалка по методам: GET, POST, PUT, PATCH, DELETE
📚 Примеры API с разбором структуры методов

👉 Базовый URL: https://vetcarega.com/
👉 Версия API: v1

👉 В каждом вопросе может быть несколько правильных ответов — нужно выбрать все.


Разбор тестирования — в конце недели.


#VetCareGA #RestApiGA

Вопросы 👇👇👇

🐾 Новый проект по REST API и GraphQL: cистема для ветеринарных клиник #VetCareGA 🐾

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

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


Спроектируем 👉REST API методы для процессов:
✅ запись питомца на приём
✅ отмена записи
✅ история записей

И отдельно покажу, как эти же сценарии можно было бы реализовать через 👉GraphQL.


📌 План:

1. Проектирование:
+ endpoint-ы и методы
+ headers
+ JSON запросов и ответов
+ алгоритмы работы
+ обработка ошибок

2. Документация:
+ постановки задач на REST API и GraphQL методы в Confluence
+ схема БД и дизайн UI/UX
+ маппинг данных: JSON - БД

3. Инструменты:
Посмотрим, как работать с REST API и GraphQL в Postman, Insomnia и Swagger (OpenAPI).


📌 В результате:
▫️ несколько постановок задач по REST API в Confluence
▫️ примеры GraphQL как альтернативы
▫️ схема БД
▫️ дизайн ключевых экранов
▫️ интерактивная документация OpenAPI (Swagger)


🎯 Кому актуален проект?
🔹 работаете аналитиком и хотите прокачать навыки работы с Backend
🔹 у вас на горизонте задачи по бронированиям, CRM или личным кабинетам
🔹 хотите научиться оформлять требования к API



🤝 Хотите участвовать и получать новый опыт в REST API и GraphQL для работы и собеседований?
Подписывайтесь на @getanalysts и следите за тегом #VetCareGA.

Добро пожаловать в команду!


#RestApiGA

📱 Tg | 💙 ВК | 💬 Max

📡 Протокол HTTP, HTTP API и его связь с REST API 📡

📌 HTTP — это протокол прикладного уровня, по которому клиент и сервер обмениваются запросами и ответами.

👉 Базовая структура HTTP API-запроса и ответа
(без архитектурного стиля REST)

Запрос:
+ HTTP-метод (GET / POST / PUT / PATCH / DELETE)
+ URL (https://api.test.com/public/v1/products?name=Яблоко&limit=10)
+ заголовки (headers)
+ тело запроса (json/xml/html/файл и др.)

Ответ:
+ HTTP статус код (200, 400, 404, 500 и др.)
+ заголовки (headers)
+ тело ответа (json/xml/html/файл и др.)



📌 REST API — это архитектурный стиль, использующий HTTP в качестве протокола передачи данных (основанный на протоколе HTTP).

👉 То есть REST API использует ту же базовую структуру HTTP-запросов и ответов.
Но добавляет рекомендации к тому, как именно проектировать API.

Например:

▫️ в REST API обычно стараются использовать HTTP-методы по назначению:
GET — чтение, POST — создание, PUT/PATCH — изменение, DELETE — удаление

▫️ в REST API обычно строят URL вокруг ресурсов, а не действий.
Для изменения продукта:
PUT /products/{id} - хорошо для REST API
POST /updateProduct/{id} - плохо для REST, хорошо для HTTP API

▫️ на практике REST API чаще всего использует JSON, хотя сам REST этого строго не требует

▫️ если в API все методы сделаны через POST, это HTTP API, но не REST



Всё самое важное про HTTP — на картинках к посту ☝️

🔗 Подробнее про связь HTTP и REST API — в статье по ссылке


#RestApiGA


📱 Tg | 💙 ВК | 💬 Max

⚠️🤖 Аналитиков сокращают и заменяют AI-агентами? Что за этим стоит.

Вижу всё больше разговоров про AI-агентов в нашем чате.
Что они уже умеют.
Что скоро “заменят аналитиков”.
Что требования, схемы, user story и документацию теперь можно просто “попросить сделать у ИИ”.

И хочу сказать важную вещь.

👉 Нет, реальность не выглядит как “аналитики больше не нужны”.
Но и делать вид, что ничего не меняется, уже нельзя.



Сейчас компании быстрее внедряют AI и AI-агентов в рабочие процессы.

И всё чаще появляется формат human-agent teams:
+ AI берёт на себя часть рутины и первые черновики,
+ человек ставит цель для AI, проверяет результат и принимает решения.

Но из этого не следует вывод “аналитиков уберут”.
Из этого следует другой вывод:

👉 у аналитиков меняются ключевые навыки.

Раньше сильный системный аналитик выигрывал за счёт того, что умел:
+ собирать информацию вручную,
+ структурировать хаос,
+ делать первые версии требований, схем и описаний,
+ прорабатывать артефакты с нуля.

Теперь часть этого ускоряет AI:
расшифровка встреч, декомпозиция требований, черновики user story, описание API, выжимка из документов, первые черновики артефактов.



И вот здесь начинается самое интересное 👇

Если часть “механической интеллектуальной работы” ускоряется, то роль аналитика смещается.
Не в сторону “кто красивее оформил требования”, а в сторону:
✔️ кто правильно понял бизнес-проблему,
✔️ кто увидел противоречия,
✔️ кто задал неудобные, но нужные вопросы бизнесу / пользователям,
❗️ кто отличил хороший AI-черновик от опасной ерунды,
✔️ кто смог собрать из AI, людей, процессов и систем работающую функциональность для бизнеса.



👉 По сути, аналитик не исчезает — он поднимается уровнем выше, начинает контролировать AI-агентов и ставить им задачи.

Теперь растёт ценность тех специалистов, кто умеет:

1. Формулировать задачу так, чтобы её вообще можно было решать.
AI может хорошо писать, но не всегда понимает, что именно нужно бизнесу.

2. Проверять и валидировать результат AI
Правдоподобный артефакт от AI ≠ корректный. Поэтому критическое мышление, проверка ограничений, корнер-кейсов и бизнес-правил становятся ещё важнее.

3. Проектировать human-in-the-loop процессы с AI (человек в цикле)
Чем больше AI в процессах, тем важнее понимать, где можно автоматизировать, а где обязательно нужен человек.

4. Работать на стыке бизнеса, архитектуры, данных и AI
Сильный аналитик понимает:
— где AI реально нужен,
— какие данные ему нужны,
— какие есть ограничения и риски,
❗️ где нужен AI-агент, а где хватит обычной автоматизации.

5. Управлять “цифровым трудом” AI
Всё больше специалистов будут не только делать руками, но и ставить задачи AI, проверять результат и выстраивать зону контроля.



И вот что лично мне кажется самым важным.

🎯 Главный риск сейчас не в том, что AI вытеснит всех аналитиков.
Просто рынок начнет делиться на две группы:
✖️ тех, кто продолжает работать “как раньше” и конкурирует с AI на уровне черновиков,
✅ и тех, кто использует AI как усилитель и сам становится дороже.

👉 Масштабная трансформация навыков будет во всех профессиях.
И аналитическое мышление для работы с AI будет цениться больше всего.

То есть вопрос:
“Нужны ли будут аналитики?”
некорректный.

Вопрос другой:
“Какие именно аналитики будут нужны?”

На мой взгляд, особенно вырастет ценность тех, кто умеет:
✅ думать системно,
✅ понимать архитектуру и интеграции,
✅ быстро разбираться в новых инструментах,
✅ валидировать результаты от AI,
✅ формализовывать правила и ограничения,
✅ проектировать процессы с участием AI,
✅ быть переводчиком между бизнесом, разработкой, данными и AI-инструментами,
⚠️ писать черновики кода с AI и быть программистами на уровне junior.

И да, возможно, моё заключение звучит не так вызывающе, как “AI-агенты всех заменят”.
Но на практике обычно побеждает не самый громкий сценарий, а самый рабочий.



👉 AI не вытесняет сильных системных аналитиков.
Он очень жёстко подсвечивает, кто реально умеет анализировать, а кто просто много лет перекладывал текст из встречи в документ 🤷‍♀️


#ai_for_analysts

💎 SSE API: что это, как работает и чем отличается от WebSocket 💎

Во многих системах нужен API, где не просто классический запрос-ответ, а доставка данных в интерфейс в реальном времени.
Один из подходов для таких сценариев — SSE.

В этом выпуске разбираем, как устроен SSE, где он встречается в реальных проектах, чем отличается от WebSocket, как влияет на архитектуру системы, безопасность и постановку задач в разработку.

🔗 Сайт эпизода с шаблоном задачи на SSE API

👉 Если вы системный аналитик, который хочет не просто знать названия технологий, а понимать — этот выпуск точно для вас.


Эпизод доступен в:

⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify

⏯ RuTube
⏯ YouTube
⏯ VK Video



🩵 GetAnalyst — ваш помощник в вопросах системного анализа и архитектуры 🤝


📱 Tg | 💙 ВК | 💬 Max

🎁 Итоги розыгрыша по Analyst Days 22 🎁

В воскресенье я рассказала о своём участии в Analyst Days 22 с докладом про ИИ:
👉 пост
Там же я разыграла скидки на билеты на конференцию.


Для подведения итогов решила воспользоваться ChatGPT 🤖
Со вторым победителем вышло забавно — ChatGPT почему-то не хотел его выбирать 🙂

Но в итоге скидки на билеты на Analyst Days 22 получают:
🎁 @ Kum** (Alina) — за комментарий в Telegram
🎁 @ Vetra** (Анна)

Поздравляю!
Связались с победителями в Telegram.

Спасибо организаторам @AnalystDaysChannel 🧡

📱 Tg | 💙 ВК | 💬 Max

✅ 42 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

📱 Tg | 💙 ВК | 💬 Max