Какие методы HTTP вы знаете и что такое идемпотентность? Какие методы идемпотентны?
Короткий ответ
- GET, POST, PUT, PATCH, DELETE — основные методы
- Идемпотентность: повтор запроса не меняет результат
- GET, PUT, DELETE идемпотентны, POST — нет
- PATCH формально не обязан быть идемпотентным
- GET ещё и безопасен — не меняет состояние
- Идемпотентность важна для ретраев и сетевых сбоев
Идемпотентный метод можно безопасно повторять: GET, PUT, DELETE — да, POST — нет.
Как сказать вслух
пример ответаОсновные методы — GET для чтения, POST для создания, PUT для полной замены, PATCH для частичного обновления и DELETE для удаления. Идемпотентность означает, что если я отправлю один и тот же запрос несколько раз, состояние сервера будет таким же, как после одного раза. GET, PUT и DELETE идемпотентны, а POST — нет: два POST создадут две записи. Это важно, когда клиент повторяет запрос после таймаута.
Подробный ответ
Основной ответ
HTTP определяет семантику методов: GET читает ресурс и считается безопасным (не меняет состояние), POST создаёт ресурс или запускает обработку, PUT полностью заменяет ресурс по известному URI, PATCH применяет частичное изменение, DELETE удаляет. Идемпотентность — свойство, при котором N одинаковых запросов дают тот же итог на сервере, что и один. GET, HEAD, PUT, DELETE идемпотентны по спецификации, POST — нет, PATCH — не гарантированно. На практике идемпотентность критична для ретраев: если клиент не получил ответ из-за обрыва сети, он может безопасно повторить идемпотентный запрос. Для POST повторяемость делают через ключ идемпотентности (Idempotency-Key), который сервер запоминает.
Ключевые моменты
- Безопасность vs идемпотентность. Безопасный метод вообще не меняет состояние (GET, HEAD). Идемпотентный может менять, но повтор не добавляет эффекта.
- POST и Idempotency-Key. Платёжные API принимают уникальный ключ в заголовке: повторный POST с тем же ключом возвращает сохранённый ответ, а не создаёт дубль.
- PUT vs PATCH. PUT присылает полное представление ресурса, PATCH — только изменения. PUT идемпотентен по определению, PATCH зависит от формата патча.
Практический контекст
В работе это всплывает при проектировании ретраев: HTTP-клиенты и прокси по умолчанию могут повторять идемпотентные запросы, но не POST. Если списание денег сделано POST-ом без ключа идемпотентности, таймаут плюс ретрай дадут двойное списание. Интервьюер смотрит, понимает ли кандидат разницу между «безопасный» и «идемпотентный» и знает ли паттерн Idempotency-Key.
Частые ошибки
- Путают безопасность и идемпотентность: DELETE идемпотентен, но не безопасен
- Утверждают, что PATCH всегда идемпотентен — спецификация этого не гарантирует
- Не могут объяснить, зачем идемпотентность нужна на практике (ретраи, сбои сети)