Ответ
Да, на уровне backend-логики это возможно, но это противоречит принципам REST и семантике HTTP.
Внутри обработчика POST-запроса можно выполнить любой код, включая SQL-запрос DELETE. Однако это создаёт путаницу в контракте API.
Проблемы использования POST для удаления:
- Нарушение идемпотентности: POST не является идемпотентным методом. Повторная отправка одного и того же запроса на удаление может привести к ошибке (например, "сущность не найдена") после первого успешного выполнения.
- Ухудшение читаемости API: Клиенты и разработчики ожидают, что DELETE означает удаление. POST — создание или сложное действие.
- Проблемы с кэшированием и стандартными инструментами.
Пример (нежелательная реализация):
POST /api/entity/remove HTTP/1.1
Content-Type: application/json
{"id": 456}Правильная RESTful-альтернатива:
DELETE /api/entities/456 HTTP/1.1Исключение — RPC-стиль API: Если ваше API построено в стиле Remote Procedure Call (RPC), где эндпоинты представляют собой действия (например, /removeEntity), то использование POST может быть оправдано. Но даже в этом случае лучше следовать общепринятым стандартам.
Ответ 18+ 🔞
Вот же ж, ну что за дичь, блядь! Технически-то, конечно, можно. Сидишь ты в своём POST-обработчике, и там хоть SQL на удаление, хоть файлы стирай, хоть сервер выключи — код выполнится, ёпта. Но это ж как взять молоток и гвозди, чтобы яйца всмятку варить — вроде инструмент в руках, но нахуя так издеваться?
Смотри, в чём тут пиздец:
-
Идемпотентность, её в рот чих-пых! DELETE — он и в Африке DELETE. Отправил запрос — запись сдохла. Отправил его же ещё раз — ну, она уже сдохла, нихуя не изменилось, всё ок. А POST? Это как тыкать в кнопку «Старт» на микроволновке, когда там уже суп греется. Один раз нажал — суп греется. Второй раз нажал — микроволновка может охуеть и выдать ошибку «Бля, я уже работаю!», или, что хуже, начать новый отсчёт и всё испортить. Так и тут: первый POST удалил запись, второй — получил в ответ «404, сущность не найдена, иди нахуй». Не порядок.
-
Читаемость API, блядь. Представь, заходит новый разработчик в проект, видит эндпоинт
POST /api/killKitten. И думает: «О, наверное, это чтобы создать нового мёртвого котёнка? Или запустить процесс убийства?». А на деле тамDELETE FROM kittens. Полный пиздец и волнение ебать. Все привыкли, что DELETE — значит удалить. Не надо выёбываться. -
Кэши, прокси, всякие умные системы — они на семантику HTTP заточены. DELETE — значит ресурс испарился, его можно из кэша выкинуть. А POST — нихуя не понятно, что случилось. Всё сломается, а потом будешь искать, почему.
Вот так делать — НЕ НАДО, блядь (но технически сработает):
POST /api/entity/remove HTTP/1.1
Content-Type: application/json
{"id": 456}Выглядит как какая-то мартышлюшка, которая боится прямо сказать, что хочет удалить.
А вот так — ПРАВИЛЬНО, красиво и всем понятно:
DELETE /api/entities/456 HTTP/1.1Кратко, ясно, семантично. Идиоматично, сука!
Хотя... есть одно «но», ебать мои старые костыли. Если у тебя весь API — это один большой RPC-стиль, где эндпоинты — это глаголы (/doSomething, /executeRemoval), то тогда да, POST — твой выбор. Но это уже не REST, а так, хитрая жопа какая-то. В 99% случаев лучше не умничать и использовать DELETE там, где нужно удалять. Не выёбывайся, короче.