Является ли DELETE идемпотентым?

Идемпотентность операции DELETE

Операция DELETE в HTTP, согласно спецификации RFC 7231, считается идемпотентной. Идемпотентность означает, что выполнение одной и той же операции многократно приводит к одинаковому результату, как если бы она была выполнена один раз. Для DELETE это означает: если мы отправляем несколько одинаковых DELETE запросов на один и тот же ресурс, итоговое состояние системы должно быть таким же, как после первого успешного запроса.

Почему DELETE является идемпотентным?

С точки зрения сервера:

• Первый успешный DELETE обычно удаляет ресурс, возвращает статус 200 OK или 204 No Content.
• Последующие DELETE запросы к тому же URI могут возвращать 404 Not Found (ресурс уже удален) или 200 OK/204 No Content, если сервер реализует "мягкое" удаление или логирует операции. Однако финальное состояние системы (ресурс отсутствует) остается неизменным после первого успешного удаления, что удовлетворяет критерию идемпотентности.

Практические примеры и исключения

Идемпотентность DELETE может нарушаться в реальных системах из-за бизнес-логики или side effects:

Пример с базой данных и триггером:

-- Таблица пользователей
DELETE FROM users WHERE id = 123;
-- Первый запрос удаляет пользователя и запускает триггер, который, например, создает запись в audit_log.
-- Повторный DELETE может не найти пользователя (id 123 уже отсутствует), но audit_log получит новую запись!

В этом случае каждый DELETE создает новую запись в audit_log, что делает операцию неидемпотентной по side effects.

Пример HTTP DELETE запроса:

import requests

# Первый DELETE
response1 = requests.delete('https://api.example.com/users/123')
print(response1.status_code)  # 204

# Второй DELETE к тому же URI
response2 = requests.delete('https://api.example.com/users/123')
print(response2.status_code)  # 404

# Результат: ресурс удален после первого запроса, состояние системы одинаково.

Важные нюансы для QA Engineer

1. Идемпотентность ≠ безопасность (safe). DELETE изменяет состояние системы, поэтому он не является безопасным (safe или read-only) методом.

2. Повторение DELETE может давать разные HTTP статусы, но это не нарушает идемпотентность, если конечное состояние ресурса одинаково.

3. Следует проверять side effects при тестировании:

   • Логирование
   • Аудит
   • Каскадные удаления в связанных таблицах
   • Вызов внешних сервисов

4. Сценарии тестирования для DELETE:

   • Удаление существующего ресурса (ожидается 200/204)
   • Повторное удаление (ожидается 404 или 200/204 с проверкой, что side effects не дублируются)
   • Удаление несуществующего ресурса (ожидается 404)
   • Удаление с неверным токеном авторизации (ожидается 401/403)

Резюме

Для QA важно понимать, что DELETE формально идемпотентен по спецификации HTTP, но в реальных API его поведение может отклоняться из-за бизнес-логики. При тестировании необходимо:

• Проверять конечное состояние системы после многократных запросов
• Отдельно тестировать side effects (аудит, логи, интеграции)
• Учитывать, что идемпотентность гарантирует одинаковое состояние ресурса, но не обязательно одинаковые ответы сервера или отсутствие побочных эффектов в других системах.