Очень часто на собеседованиях прилетает вопрос про REST API

И не важно, бизнес-аналитик ты или системный. По этим темам спрос есть везде, поэтому разбираемся 🔦

(набираем 99 реакций и я продолжаю рубрику вопросов с собесов)

1) Поясни простыми словами, что такое REST?
2) Окей, а что такое API?
3) Тогда что значит REST API?
4) В чём разница между REST API и RESTful API?

В эти моменты у некоторых ребят тряска и максимум выдают что-то вроде этого:

Ну… REST — это какой-то протокол обмена данными… API — это типа программный интерфейс… RESTful — это тоже REST, только более правильный.

Такой ответ сразу палит, что ты знаешь всё поверхностно и руками в интеграции не лез.

😌 А вот хороший ответ звучит по-другому:

1. API — это программный интерфейс для общения между системами.
2. REST — это архитектурный стиль проектирования веб-сервисов, который определяет правила взаимодействия: stateless (отсутствие состояния), идентификация ресурсов, работа через HTTP-методы, кэширование и использование общепринятых форматов данных (например, JSON).
3. REST API — это реальный API, который реализован по принципам REST: работа с ресурсами, обмен данными через HTTP-методы (GET/POST/PUT/PATCH/DELETE и т.д.), данные возвращаются в едином формате (чаще JSON).
4. RESTful и REST API — в обоих случаях речь идет о системах, которые позволяют взаимодействовать в соответствии с архитектурой REST, но RESTful — это термин, который подчёркивает строгое следование принципам REST.

И вот тут есть еще один лайфхак. Если тебя гоняют по REST и RESTful, можно разбавить практикой. Расскажи, например, что у вас был сервис, но в нём часть запросов реализовали через POST вместо GET. Это не RESTful, но рабочее решение, которое оказалось быстрее в реализации.

Вот это интервьюеры любят. Потому что в реальной жизни чистый REST встречается редко. И хороший кандидат не только знает теорию, но и понимает, как она работает на практике.

Вообще, стоит запомнить простую формулу 😑

API — «как общаемся»,
REST — «по каким правилам»,
REST API — «API по этим правилам»,
RESTful — «строго и последовательно по REST».

Ребят, хочу собрать от вас сегодня вопросы ❓

Пишите в комментарии под этим постом всё, что интересно: резюме, собеседования, компании, темы из БА и СА.

Даже если думаете, что вопрос глупый, но разобраться самостоятельно не получается 🥲

Сегодня до 19:00 я выберу самые острые и популярные вопросы, подробно отвечу на них в гс в канале.

Жду 👇

Как и обещал, отвечаю на ваши вопросы из комментариев к этому посту ❓

00:16 — Как составить резюме и портфолио без опыта
02:10 — Самые частые ошибки в резюме (разбор в постах: часть 1, часть 2)
02:36 — Использование ИИ в работе аналитика
04:21 — Описание требований с помощью ИИ
05:46 — Как быстро влиться в новую команду (подробный пост)
07:52 — Карьерный рост аналитика по грейдам
08:22 — Junior: с чего начинается путь
08:38 — Middle: ключевые отличия
09:54 — Lead: чем отличается работа и зона ответственности
10:53 — Как растёт зарплата вместе с грейдом

Кстати, осенью на моём ютуб канале выйдет полноценная лекция по теме ИИ 📱

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

Разбор вопроса с собеса в ВТБ на 250К💰

«Как работаете с интеграциями? Какой порядок действий? Что вообще делаете?»

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

Что важно помнить:

1⃣ Интеграции бывают разные, и процесс зависит от команды и компании: кто-то работает с готовыми API, кто-то с устаревшими SOAP-сервисами, кто-то с брокерами сообщений.

2⃣ Никто не ждёт от тебя идеального сценария. Смотрят именно структуру действий и как ты решаешь проблемы.

Тут работает один лайфхак: перед тем как отвечать, задай уточняющие вопросы, например:

Сколько систем участвует? Какие протоколы? Есть ли обработка ошибок?

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

😌 Хороший ответ может звучать так:

1. Понимаю задачу.
Уточняю, что нужно интегрировать, какие системы участвуют, какие данные передаются.

2. Собираю требования.
Интервью с владельцами систем, проверка документации, уточнение ограничений и форматов данных, прошу примеры запросов/ответов, права доступа, ограничения.

3. Проектирую решение.
Определяю точки интеграции, протоколы (REST, SOAP, брокеры сообщений), формат сообщений (JSON, XML), частоту обмена, механизм обработки ошибок, документирую логику взаимодействия.

4. Создаю задачи.
Декомпозирую интеграцию на задачи: разработка, тестирование, настройка, мониторинг.

5. Тестируем и валидируем.
Проверяем корректность передачи данных, ошибки формата, обработка сценариев отказов.

6. Ведение и поддержка.
Логи, мониторинг, уведомления о сбоях.

Этот вопрос — идеальная возможность задать свои встречные вопросы. Покажи, что уверенно вникаешь в контекст будущей работы. Ведь у разных команд и компаний интеграции делаются очень по-разному: где-то от аналитика ждут только «вот url и схема запроса», а где-то он должен продумать весь контракт, сценарии ошибок и модель данных.

Типичные ошибки при ответе:
🔵 ответить «я просто урл описываю» — звучит бедненько.
🔵 сказать «ну интеграции бывают разные, зависит от команды» и не привести примеров.
🔵 не задать уточняющие вопросы (а это был твой шанс показать любопытство и глубину).
🔵 сказать «не знаю» — про такой ответ можно вообще забыть.

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

Есть среди моих читателей те, кто работает в ВТБ или проходил туда собеседования — рассказывайте, как вам 🤔