Junior Level

HTTP методы — это команды, которые говорят серверу, что нужно сделать с ресурсом.

Основные методы:

Метод	Действие	Пример	Описание
GET	Чтение	GET /users/1	Получить данные (не меняет ничего)
POST	Создание	POST /users	Создать новый ресурс
PUT	Полное обновление	PUT /users/1	Заменить ресурс целиком
PATCH	Частичное обновление	PATCH /users/1	Обновить часть ресурса
DELETE	Удаление	DELETE /users/1	Удалить ресурс

Свойства методов:

Метод	Безопасный (Safe)	Идемпотентный
GET	Да	Да
POST	Нет	Нет
PUT	Нет	Да
PATCH	Нет	Зависит от реализации
DELETE	Нет	Да

• Безопасный (Safe): Метод не изменяет состояние сервера
• Идемпотентный: Повторный вызов с теми же параметрами даёт тот же результат

Дополнительные методы:

• HEAD: Как GET, но без тела ответа (для проверки существования)
• OPTIONS: Узнать, какие методы поддерживаются для ресурса (используется в CORS)

---

Middle Level

POST: Универсальный инструмент

POST — единственный метод, который не является идемпотентным. Он используется:

• Для создания ресурсов
• Для запуска процессов (/jobs/1/start)
• Для сложного поиска с большим телом запроса

Pitfall: Браузеры при нажатии “Назад” после POST выдают предупреждение “Подтвердите повторную отправку формы”.

PUT vs PATCH

• PUT требует передачи всего состояния. Если забыли поле — сервер должен его обнулить
• PATCH экономит трафик (заметно на больших объектах с 50+ полями), но сложнее в реализации. Сервер должен различить: поле отсутствует в запросе (не трогать) или явно передано как null (установить в null).

HEAD и OPTIONS: Невидимые герои

• HEAD: Возвращает заголовки без тела. Используется для проверки ETag, Content-Length
• OPTIONS: Используется в CORS. Браузер делает “Preflight request” перед кросс-доменными запросами

TRACE и CONNECT

• TRACE: Возвращает запрос клиента обратно. Опасен атаками Cross-Site Tracing (XST). В продакшене всегда отключайте TRACE. В изолированной dev-среде может быть полезен для отладки прокси.
• CONNECT: Для создания туннелей (через прокси для HTTPS). В обычных REST API не используется.

Диагностика

• 405 Method Not Allowed: Проверьте заголовок Allow — сервер обязан вернуть список разрешённых методов
• Spring Security: CSRF-защита включена для всех методов, кроме GET, HEAD, OPTIONS, TRACE

---

Senior Level

Матрица свойств (RFC 9110, 2022 — заменил RFC 7231)

Метод	CRUD	Safe	Idempotent	Cacheable
GET	Read	✅	✅	✅
POST	Create/Action	❌	❌	⚠️*
PUT	Replace	❌	✅	❌
PATCH	Partial Update	❌	⚠️**	❌
DELETE	Delete	❌	✅	❌

*POST может быть кэшируемым, если установлены соответствующие заголовки (редко). *PATCH идемпотентен, если логика обновления детерминирована (например, JSON Merge Patch).*

Проблема идемпотентности DELETE

Если DELETE /users/1 возвращает 200, а второй вызов 404 — это всё равно идемпотентно. Идемпотентность — это состояние сервера, а не код ответа.

Method Tunneling

Некоторые старые прокси не поддерживают PATCH. Решение: POST /resource с заголовком X-HTTP-Method-Override: PATCH.

Pre-fetching и безопасность GET

Браузеры могут заранее вызывать GET-методы. Если GET не “Safe” (например, GET /logout), это приведёт к случайному выходу пользователя.

Highload

• Идемпотентность влияет на возможность автоматических повторов запросов
• POST нельзя автоматически повторять при тайм-ауте (риск двойных оплат)
• Service Mesh (Istio, Linkerd) автоматически повторяет идемпотентные запросы при 503

---

🎯 Шпаргалка для интервью

Обязательно знать:

• 5 основных методов: GET (чтение), POST (создание), PUT (полное обновление), PATCH (частичное обновление), DELETE (удаление)
• GET — безопасный (Safe) и идемпотентный, не должен менять состояние сервера
• POST — единственный метод, который не является идемпотентным
• PUT всегда идемпотентен (полная замена ресурса), DELETE тоже идемпотентен
• PATCH идемпотентен только если операция детерминирована (replace — да, add — нет)
• HEAD возвращает заголовки без тела (для проверки ETag, Content-Length)
• OPTIONS используется в CORS preflight запросах
• TRACE и CONNECT в обычных REST API не используются; TRACE опасен XST-атаками

Частые уточняющие вопросы:

• Почему POST не идемпотентен? — Каждый POST может создать новый ресурс (5 POST = 5 заказов)
• Можно ли использовать GET для удаления? — Нет, GET обязан быть безопасным; браузеры могут предзагружать GET
• Когда использовать PATCH вместо PUT? — Для больших объектов или когда несколько клиентов меняют разные поля параллельно
• Что возвращает OPTIONS? — Список разрешённых методов для ресурса (заголовок Allow)

Красные флаги (НЕ говорить):

• «POST можно безопасно повторять при тайм-ауте» — это риск двойных операций
• «GET может менять данные, это нормально» — GET обязан быть Safe по RFC
• «PATCH всегда идемпотентен» — зависит от реализации (add в массив — не идемпотентно)
• «TRACE полезен в продакшене» — TRACE опасен Cross-Site Tracing атаками

Связанные темы:

• [[Что такое идемпотентность (idempotency)]]
• [[Какие HTTP методы идемпотентны]]
• [[Почему GET и DELETE идемпотентны]]
• [[Является ли POST идемпотентным]]
• [[В чём разница между PUT и PATCH]]