Можно ли запросом DELETE получить данные
Что проверяют
Знаете ли вы семантику HTTP-методов, а не только их названия. Интервьюер ждёт, что вы разведёте две вещи: тело ответа на DELETE и чтение данных через DELETE. Следом часто спрашивают про идемпотентность и про то, можно ли передать тело в самом запросе.
Как отвечать
Ответ на DELETE вернуть данные может, и это нормально. RFC 9110 описывает три типичных успешных ответа:
200 OK: с телом, например удалённый объект или описание результата;202 Accepted: запрос принят, но удаление ещё не выполнено, скажем, поставлено в очередь;204 No Content: удалено, тела нет.
А вот использовать DELETE как способ получить данные нельзя. Метод небезопасный в терминах HTTP: он меняет состояние сервера, а его ответ не кэшируется ни браузером, ни CDN. Для чтения есть GET.
Тело в самом запросе DELETE формально не запрещено, но стандарт говорит, что у него нет определённой семантики, и часть серверов и прокси такое тело отбрасывает или отклоняет запрос целиком. Фильтры для массового удаления надёжнее передать в query-параметрах или сделать отдельный POST /items/bulk-delete.
На фронтенде это видно прямо в коде:
fetch: на ответе204вызовresponse.json()упадёт сSyntaxError, потому что тела нет. Проверяйте статус перед разбором;- axios: сигнатура
axios.delete(url, config), тело запроса передаётся черезconfig.data, а не вторым аргументом, как вpost; - CORS:
DELETEне входит в простые методы, поэтому на чужой домен браузер сначала шлёт preflightOPTIONS.
Метод идемпотентен: повторный DELETE оставляет сервер в том же состоянии, хотя код ответа может смениться на 404.
Где спотыкаются
Отвечают «нет, DELETE ничего не возвращает». Возвращает, 200 с телом встречается постоянно.
Уходят в обратную крайность: «можно, если сервер так сделал». Технически да, но вы теряете кэш, безопасность повторного запроса и понятный контракт API.
Путают идемпотентность с одинаковым ответом. Идемпотентность описывает состояние сервера, а не статус: первый вызов даёт 204, второй 404, и это корректно.