🔥 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
После первого запроса пользователя нет.
После второго пользователя по-прежнему нет.
Ответы могут отличаться, но итоговое состояние одинаковое.
Продолжение ➡️
#RestApiGA
