Можно ли создавать данные через HTTP метод DELETE

Что проверяют

Различаете ли вы «сервер это позволит» и «такую семантику задаёт протокол», и понимаете ли, чем грозит нарушение идемпотентности. Для тестировщика это ещё и вопрос о том, какие проверки вы напишете на удаление.

Как отвечать

Технически сервер может делать на DELETE что угодно: побочные эффекты метод не запрещает, и тело в запросе отправить можно. Но семантика тела у DELETE спецификацией не определена, и прокси, балансировщики и клиентские библиотеки спокойно его выбрасывают, так что закладываться на это нельзя.

Настоящий аргумент не в чистоте REST, а в идемпотентности. DELETE обязан быть идемпотентным: повторный вызов оставляет систему в том же состоянии. На этом свойстве построены повторы после таймаута у клиентов, шлюзов и очередей. Если метод создаёт запись, повтор создаст вторую, и обычный ретрай после обрыва связи начнёт плодить данные.

Отдельно разведите случаи. Запись в журнал аудита, отметка об удалении, перенос объекта в корзину: это побочные эффекты удаления, они нормальны и идемпотентность не ломают. А создание нового ресурса по запросу пользователя это POST, тогда как PUT создаёт ресурс по заранее известному адресу и тоже идемпотентен.

Где спотыкаются

Первое: спорят про коды ответа вместо состояния. Что вернёт второй DELETE, 204 или 404, вопрос договорённости в конкретном API, а вот вторая строка в базе это уже дефект. Проверять надо состояние системы, а не только код ответа.

Второе: не тестируют повтор и одновременность. Два одинаковых запроса подряд и два параллельных дают разные эффекты, и именно там всплывают дубликаты, каскадные удаления лишнего и осиротевшие связи.

Третье: забывают про мягкое удаление. Если строка лишь помечается флагом, она остаётся в таблице, и уникальные ограничения продолжают действовать: создать объект с тем же адресом почты не получится. Это проверяют отдельно, из интерфейса такое поведение не видно.