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]]