Да, можно. И очень часто — даже нужно.

Представьте старый банк: толстые папки с делами клиентов, курьеры с подписанными бумагами, архивариусы и полки, которые никто не имеет права сразу отправить в шредер. Почему? Потому что закон обязывает хранить документы 3, 5, а иногда и 10+ лет. С переходом на цифру мало что изменилось.

ЭЦП появилась, электронный документооборот тоже, а вот требования регуляторов к срокам хранения данных — почти нет. Поэтому «удалить клиента навсегда» в большинстве компаний просто невозможно. Что мы делаем на практике? Чаще всего применяем мягкое удаление (soft delete):- помечаем клиента как не активного, переносим данные в архивные таблицы, оставляем возможность восстановления. И вот тут возникает интересный момент с HTTP-методами.

Классический REST говорит:DELETE /clients/12345, но что на самом деле происходит за этим «удалением»? Обычно целый бизнес-процесс: перенос в архив, создание записи в аудите, уведомление связанных систем, запуск таймера на окончательное уничтожение данных через N лет, логирование причины удаления. Это уже не простое «убери строку из таблицы». Это операция, у которой есть смысл, причина, последствия и участники. Когда POST уместнее

httpPOST /clients/12345/deactivate

POST /clients/12345/archive

POST /client/delete

С телом: JSON{"clientId": 12345,"reason": "customer_request","comment": "Клиент попросил удалить все данные"}

Такой подход лучше отражает бизнес-смысл операции. Такой подход лучше отражает бизнес-смысл операции. Вывод для системных аналитиков

DELETE отлично работает, когда вы действительно хотите логического удаления и внутри сервиса всё делаете сами (soft delete + аудит).

POST становится предпочтительнее, когда «удаление» — это сложный orchestrated процесс с несколькими шагами, интеграциями и бизнес-правилами.

Главное правило:Название эндпоинта и его поведение должны быть понятны команде, разработчикам и тем, кто будет поддерживать систему после вас. Документация — ваш лучший друг.

А у вас как принято «удалять» сущности?

Пишете DELETE, используете POST /.../deactivate или придумали свой подход?Делитесь в комментариях — будет интересно сравнить практики из разных доменов (банки, e-commerce, SaaS и т.д.).