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

🔥 10 спорных вопросов по REST API, ответы на которые важны для работы и собеседований 🔥 [ЧАСТЬ 2]

Проверьте себя 👇
Сначала ответьте на вопросы, потом раскройте ответы.

Считайте итоговый балл вместе с частью 1 в предыдущем посте.


7️⃣ Может ли POST быть идемпотентным?

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

Сам метод POST по стандартной семантике идемпотентным не считается (подробнее тут).

Например, повторное создание платежа можно защитить с помощью:

▫️ Idempotency-Key - ключа идемпотентности
▫️ уникального идентификатора операции
▫️ бизнес-ключа заказа, который будет проверяться
▫️ проверки ранее созданного результата

POST /payments
Idempotency-Key: payment-order-123

При повторном запросе сервер не создаёт второй платёж, а возвращает результат первой операции.


Но эту гарантию необходимо явно описать в контракте API и спроектировать в алгоритме.

Без этого операция выполнится несколько раз и создаст несколько платежей.



8️⃣ Чем статус HTTP-401 отличается от 403?

401 Unauthorized — клиент не прошёл аутентификацию:
▫️ неверная пара логин+пароль
▫️ токен отсутствует
▫️ токен недействителен
▫️ токен истёк

403 Forbidden — сервер понял запрос, но не разрешает выполнить операцию из-за отсуствия прав доступа. Это ошибка авторизации.

Например, пользователь авторизован, но у него нет роли администратора.

В отдельных системах вместо 403 могут намеренно возвращать 404 (не найдено, нет данных), чтобы не раскрывать существование защищённого ресурса.



9️⃣ PUT используется только для обновления существующего объекта?

Нет.

PUT означает создание или полную замену состояния ресурса по известному клиенту URI.

Пример:
PUT /users/9991112233 - создать или изменить пользователя

В зависимости от контракта сервер может:

▫️ заменить существующий ресурс
▫️ создать его, если ресурса ещё нет
▫️ запретить создание и вернуть ошибку

Для частичного изменения обычно используется PATCH.


🔟 Некорректное значение поля: 400 или 422?

Клиент отправил корректный JSON:

POST /users
Content-Type: application/json

{
  "email": "anna@example.com",
  "age": -5
}

Какой HTTP-статус вернуть?


Возможны оба варианта в зависимости от принятого стандарта API внутри проекта.

400 Bad Request — неверный формат — часто используют для любых ошибок входных данных:

▫️ некорректный JSON
▫️ отсутствующее обязательное поле
▫️ неправильный формат
▫️ недопустимое значение


422 Unprocessable Content — ошибка бизнес-логики — точнее показывает, что:

▫️ JSON синтаксически корректен
▫️ сервер понял структуру запроса
▫️ но не может обработать данные из-за нарушения правил валидации


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

Главное — не выбирать код заново для каждого метода, а зафиксировать единый подход в корпоративном гайде по API.


=========================

Сколько ответов у вас совпало?

😱 0–3
👍 4–6
🔥 7–8
🦄 9–10

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

=========================

📚 Дополнительный разбор спорных вопросов по REST API
Статья была опубликована в 2023 году, поэтому нового метода QUERY в ней ещё нет. Но остальные вопросы всё ещё регулярно встречаются на проектах и собеседованиях.



Сохраняйте, точно пригодится перед следующим техническим интервью 💙


#hardGetAnalyst

🔥 10 спорных вопросов по REST API, ответы на которые важны для работы и собеседований 🔥 [ЧАСТЬ 1]

Проверьте себя 👇
Сначала ответьте на вопросы, потом раскройте ответы.


1️⃣ Можно ли использовать POST для получения данных?

Да.

1) Много фильтров для GET

Когда условий поиска много, URL перегружается query-параметрами и может стать слишком длинным:

GET /products?brand=Apple&category=phones&priceFrom=500&priceTo=1500&ratingFrom=4...

Фильтры удобнее передать JSON-объектом в теле запроса.

Но семантика тела для GET не определена: некоторые серверы, прокси и другие промежуточные компоненты могут его не поддержать или проигнорировать.

Поэтому для сложного поиска традиционно используют POST.

Пример на поиск продуктов в каталоге:

POST /products/search
Content-Type: application/json

{
"brands": ["Apple", "Samsung"],
"ratingFrom": 4,
"priceTo": 1000
}


Но POST по стандартной семантике не является безопасным и идемпотентным методом, поэтому обоснование такого решения необходимо явно описать в API-документации.

С июня 2026 года для таких сценариев стандартизирован новый HTTP-метод QUERY:
QUERY /products

2) Для асинхронного получения данных.
Например, для отчетов:
POST /report - запускает асинхронную задачу на сбор данных для отчета
GET /report/{id} - получаем результирующие данные или файл отчета



2️⃣ Можно ли передать JSON-тело в GET?

Технически тело в GET передать можно, но его использование не ожидается.

Клиенты, серверы, прокси или API Gateway могут:

▫️ проигнорировать body
▫️ удалить его
▫️ отклонить запрос
▫️ обработать его не так, как ожидается

Поэтому передавать фильтры в body метода GET не стоит, особенно для публичного или интеграционного API.

Для передачи любых данных в GET используйте query-параметры, POST или новый QUERY.



3️⃣ Можно ли сделать все методы API через POST?

Технически — да.
Рекомендуется — нет.

Такой API может работать, но клиентам может быть сложнее понять назначение операций:

▫️ где чтение данных
▫️ где создание
▫️ где полная или частичная замена
▫️ и т.д.

Это будет скорее HTTP API с RPC-подобным дизайном, чем ресурсно-ориентированный REST API.

❗️ Исключение — если такой подход уже принят в действующем API. Тогда важнее сохранить единообразие или версионировать изменения, чем добавить один «идеальный» PATCH среди сотни POST.

Примеры:
https://dadata.ru/api/
https://www.unisender.com/ru/support/api/common/bulk-email/



4️⃣ Какой код должен вернуть успешный POST: 200 или 201?

Зависит от логики и результата выполнения.

▫️ 201 Created — создан новый ресурс, т.е. новая запись в БД [POST /products — создать продукт]

▫️ 200 OK — запрос обработан, но отдельный ресурс не создавался [POST /products/search — искать продукт, если много фильтров отправили в JSON]

▫️ 202 Accepted — запрос принят, но обработка ещё не завершена, задача поставлена в очередь [POST /reports — создать задачу на генерацию отчета]

▫️ 204 No Content — операция выполнена успешно, но возвращается пустое тело ответа.

Сам HTTP-метод не определяет единственный допустимый код ответа.
На практике в REST API могут вообще все HTTP-200 быть для успеха.



5️⃣ Запрос с фильтром не нашёл ни одного объекта. Возвращать 200 OK или 404 Not Found?

GET /products?brand=Unknown

Обычно:
200 OK
[]

или лучше:
200 OK
{
"limit": 10,
"offset": 0,
"count": 0,
"products": []
}

Коллекция /products существует, запрос корректен, но подходящих элементов нет.

404 Not Found логичнее использовать, когда не найден конкретный ресурс:
GET /products/123

Главное — зафиксировать единый подход в гайде по дизайну API и контракте метода.



6️⃣ DELETE считается идемпотентным, если первый запрос вернул 204, а повторный — 404?

Да.

Идемпотентность не требует, чтобы повторные запросы возвращали одинаковые ответы.

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

DELETE /users/123

После первого запроса пользователя нет.
После второго пользователя по-прежнему нет.

Ответы могут отличаться, но итоговое состояние одинаковое.


Продолжение ➡️

#hardGetAnalyst

❤️‍🔥 Доступ завершается завтра: практика по ИИ и REST API ❤️‍🔥

Полноформатное обучение, в котором вы практикуетесь с ИИ-инструментами и погружаетесь в REST API.


❤️‍🔥 ИИ для работы аналитика: практика на задачах с REST API

🗓 Доступ до 11 августа
🕘 Время на обучение: 4.5 часа

🔗 Получить доступ


👉 На практике вы:

➕ настроите ИИ-агента для работы с API-задачами
➕ исследуете запросы к реальным API через Postman и Insomnia
➕ разберётесь, как работать со Swagger и OpenAPI-документацией
➕ поймёте, какие задачи можно передавать ИИ, а где необходима проверка аналитика

👉 Разберёте 10+ инструментов для работы с ИИ и API:

✔️ Qwen
✔️ ChatGPT
✔️ Claude
✔️ Postman
✔️ Insomnia
✔️ Swagger
✔️ и другие



👉 Этот практикум — самостоятельное полноформатное занятие, которое можно пройти и использовать отдельно от наших программ.

Он также является вводным занятием к практическим программам:

🎓 Проектирование REST API
Старт 11 августа
Завтра — последний день предзаписи по специальным условиям.

🎓 ИИ-Акселератор
Старт 29 августа
Для тех, кто хочет глубже освоить ИИ для рабочих задач.



Успевайте посмотреть, пока открыт доступ 🤝

Друзья, желаем результативной недели 👌

❤️‍🔥🤖 ИИ-агенты для аналитика: к концу практикума можно стать сеньором [8-11 августа] 🤖❤️‍🔥

«к концу практикума можно стать сеньором» 😄

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

Конечно, за 4 часа сеньором не стать.

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



❤️‍🔥 ИИ для работы аналитика: практика на задачах с REST API

🗓 Доступ только с 8 по 11 августа

📹 Формат: в записи
🕐 На обучение: 4 часа
🟢 Участие бесплатное

🔗 Зарегистрироваться



👉 На практике вы:

➕ настроите ИИ-агента для работы с API-задачами
➕ исследуете запросы к реальным API через Postman и Insomnia
➕ разберётесь, как работать со Swagger и OpenAPI-документацией
➕ поймёте, какие задачи можно передавать ИИ, а где необходима проверка аналитика

👉 Разберём 10+ инструментов для работы с ИИ и API:

✔️ Qwen
✔️ ChatGPT
✔️ Claude
✔️ Postman
✔️ Insomnia
✔️ Swagger
✔️ и другие



👉 Этот практикум — самостоятельное полноформатное занятие, которое можно пройти и использовать отдельно от наших программ.

Он также является вводным занятием к практическим программам:

🎓 Проектирование REST API
Старт 11 августа
Завтра — последний день предзаписи по специальным условиям.

🎓 ИИ-Акселератор
Старт 29 августа
Для тех, кто хочет глубже освоить ИИ для рабочих задач.



——

P.S. Технические или организационные вопросы: @getanalyst или info@getanalyst.ru

📚🤖 AI-помощник для подготовки к собеседованию по REST API 📚🤖

Вопросы и задачи с собеседований — это всегда отличный способ размяться перед реальным интервью и вспомнить то, что давно не использовали в работе.

Прикрепила к посту два файла:
1. Только вопросы - файл "Задания к собеседованию"
2. Эти же вопросы, но с ответами - файл "Вопросы и ответы"


🤖 Инструкция по подготовке к интервью с помощью AI:

👉 1. Скачайте pdf-файл с ответами из этого поста (второй по порядку).


👉 2. Откройте ChatGPT и войдите в бесплатный аккаунт, используя свою учетную запись Google.
https://chatgpt.com/
Альтернативный инструмент:
https://gemini.google.com/
(больше лимиты на бесплатном тарифе)


👉 3. Откройте новый диалог (New Chat в левом меню).


👉 4.1. Загрузите файл в ChatGPT.
В зоне ввода текста есть иконка "+".
Нажмите на неё и появится иконка скрепки с надписью "Добавить файл" (Add photos & files").

👉 4.2. Вставьте промпт:

Представь, что ты ведущий системный аналитик с опытом более 10 лет в IT. Ты хочешь нанять senior системного аналитика к себе в команду и я пришёл к тебе на техническое собеседование.

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

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

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

Чередуй вопросы по теории и практические задания, задачи как на реальных проектах.

Сразу после этого сообщения можешь задать мне первый вопрос.

👉 5. Ваше собеседование началось.
Отвечайте на вопросы.



❗️ Не печатайте текст на теоретические вопросы, а говорите ответы голосом, где возможно!
Используйте иконку "микрофон", чтобы записывать свои ответы и отдавать их на проверку Искусственному Интеллекту.
Получайте обратную связь от ИИ и улучшайтесь 😌


+ В помощь на собеседования:
JSON Editor Online


Сохраняйте и пользуйтесь.
Сейчас или в будущем 🤝


🔥 и 🩷 приветствуются))


#hardGetAnalyst

💜 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 проще понять, что делает метод, с каким ресурсом он работает и какие данные от него ожидать.


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

#hardGetAnalyst

Каждый идёт учиться со своими запросами и целями. «Систематизировать знания» — один из самых частых. С таким запросом на программу «Дизайн REST API» пришла Алёна.

Далее со слов Алёны👉

#студентыGetAnalyst

⚡️ [8-11 августа] ИИ для работы аналитика: практика на задачах с REST API ⚡️

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

Но просто написать в ChatGPT «сделай требования» недостаточно.

Нужно уметь правильно поставить задачу, передать контекст и проверить результат. Этому и будем учиться на практикуме на следующей неделе 👇


🤖 ИИ для работы аналитика:
практика на задачах с REST API

🗓 Доступ с 8 по 11 августа

📹 Формат: практикум в записи, смотрите в удобное время
🟢 Участие бесплатное

🔗 Зарегистрироваться


На практике разберём:
▫️ какие задачи аналитика можно передать ИИ;
▫️ как настроить ИИ-агента для работы с API;
▫️ как выполнять и исследовать запросы через Postman и Insomnia;
▫️ как читать и создавать с ИИ Swagger-документацию (OpenAPI).


В результате вы:
✅ настроите ИИ-агентов под свои задачи
✅ выполните реальные API-запросы
✅ поймёте, как ускорять работу с REST API без слепого доверия к ИИ


Практикум будет полезен системным, бизнес- и начинающим аналитикам, которые хотят увереннее работать с API и современными ИИ-инструментами.

ИИ не заменит аналитика, который умеет думать.

Но аналитик с ИИ будет востребованнее того, кто продолжает всё делать вручную 🚀

Присоединяйтесь с 8 по 11 августа!


——
Вопросы? Пишите @getanalyst или info@getanalyst.ru

📚 Книги по API, которые рекомендую к прочтению 📚

Если вы хотите научиться проектировать REST API или готовитесь к собеседованиям на системного аналитика, то это одни из немногих книг, которые реально формируют мышление «API-дизайнера», а не просто перечисляют HTTP-методы 👇


📚 "Проектирование веб-API", Лоре Арно

Цитаты:

✅ Что вы делаете, когда впервые используете какую-либо повседневную вещь? Вы внимательно смотрите на ее интерфейс, чтобы определить ее назначение и то, как ее использовать, основываясь на том, что вы видите, и на своем прошлом опыте. И здесь важен дизайн.

✅ Если вы сосредоточитесь на том, что происходит «под капотом», это приведет к полной катастрофе. Если сфокусироваться на том, что могут делать пользователи, – все пройдет гладко.

✅ Любое представление должно быть легко понятно для людей и программ.

🔗 Читать отрывок



📚 "RESTful Web API паттерны и практики. Связывание и оркестрация микросервисов и распределение данных", Майк Амундсен

Цитаты:

✅ Основной сложностью проектирования успешных API сервисов является необходимость балансировать между стабильностью и возможностью развиваться.

✅ Одной из сложностей при создании гибких клиентов API является обработка всех деталей каждого НТТР-запроса.

🔗 Купить на Литрес
🔗 Читать отрывок



Добавляйте в свой TO DO лист к прочтению 🤝

#hwGetAnalyst

#GAhahaha

❗️ Новый HTTP-метод QUERY: значительное изменение стандарта впервые за 16 лет ❗️


👉 Новый стандарт RFC 10008 от 15 июня 2026
https://www.rfc-editor.org/info/rfc10008/
добавил новый HTTP-метод "QUERY".

Стандарт появился.
Теперь ждём, когда инструменты и инфраструктура массово обновятся👌