🔥 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