В различных источниках, пишущих об идемпотентности, вы можете встретить такие термины, как "система", "сервер" и "БД". Имейте в виду, что строго в рамках этого контекста мы их будем считать взаимозаменяемыми.

1) Что такое идемпотентность метода?
Ответ: Когда повторный вызов с теми же параметрами не меняет состояние сервера.
Пример: DELETE /users/123 - первый вызов удалил пользователя, второй ничего не меняет; ресурс по-прежнему отсутствует.

2) Что значит идемпотентный метод? 
Ответ: Метод называют идемпотентным, если его повторный вызов с теми же параметрами не меняет состояние сервера.

3) Какие HTTP-методы считаются идемпотентными? А какие нет?
Ответ:
Идемпотентные: GET, PUT, DELETE, HEAD, OPTIONS.
Неидемпотентные: POST, PATCH.

Дополнение: Это «по стандарту», но реальная реализация может нарушать правило (например, GET пишет счётчик просмотров в БД).

4) Чем безопасные (safe) методы отличаются от идемпотентных?
Ответ: Safe = метод не изменяет состояние (read only методы, например, GET, HEAD, OPTIONS).
Идемпотентность допускает одно изменение, но повторные вызовы больше ничего не меняют (PUT, DELETE).
Пример: GET - безопасен и идемпотентен. DELETE - не safe, но идемпотентен.

Дополнение: Все безопасные методы по стандарту - идемпотентные.
Но идемпотентный метод может быть не безопасным (например, пример с DELETE - меняет данные при первом вызове, но повторный вызов уже не меняет состояние.) 
Талица безопасных и идемпотентных методов:

Ответ: Выполнить запрос два и более раза с одинаковыми параметрами, сравнить статус/тело/заголовки, и проверить побочные эффекты в базе/логах.

Пример:

1. Первый запрос.

2. Повторный запрос.

3. Снимок состояния до/после (запрос в БД, логи).

Ожидание: состояние неизменно на повторе для идемпотентных методов.

Ответ: Неверная реализация: каждый GET /products увеличивает views_count (счетчик просмотров) в базе данных.

Ожидаемое поведение: GET не должен менять состояние.

Ответ:

1. Создать ресурс.

2. DELETE /resource/id - 204.

3. Повторить DELETE /resource/id → 404 или 204 без изменений состояния.

4. Проверить, что в БД нет «воскресшего» ресурса и в логах нет побочных операций.

Пример скачивания репорта: GET /api/download-report?date=2025-08-10 Ожидание: повторные вызовы возвращают тот же файл, заголовки одинаковы; в БД/логах нет не ожидаемых изменений.

Антипример: инкремент счётчика скачиваний (download_count) в базе данных - нарушение идемпотентности GET.

Пример:

Имя: Нарушена идемпотентность метода X

Шаги: выполнить запрос N раз с одинаковыми параметрами.

Ожидаемый результат: состояние системы не меняется после первого вызова; ответ идентичен.

Фактический результат: изменился счётчик/создался дубль/ушло второе письмо.

Дополнения: SQL-запросы, логи, скрин Postman.

Риски: дубликаты транзакций, повторные нотификации, расхождение метрик.

Ответ: По стандарту - нет. На практике: например, можно добиться идемпотентного поведения с Idempotency-Key. Проверять, что повтор метода POST с тем же ключом не создаёт дубликаты и отдаёт тот же ответ.

Напоминание:
REST не является жёстким стандартом!

REST - это договорённость/идея: разработчики договариваются, как описывать ресурсы, какие методы использовать, как строить URL, как возвращать ответы.

Можно “нарушать”: технически никто не мешает сделать DELETE /users для создания пользователя или POST /orders/123 для удаления заказа.

НО: если отходить от общепринятых практик, API становится непредсказуемым, и его сложнее тестировать, поддерживать и документировать.

Полезные ссылки:
Спецификация протокола HTTP 1.1
Что такое ИДЕМПОТЕНТНОСТЬ, или история Васи и его приложения
PDF-файл: