Чем отличаются HTTP методы GET, POST, PUT, PATCH, DELETE?

Основные HTTP методы и их семантика

HTTP методы (часто называемые HTTP-глаголами) определяют тип операции, которую клиент хочет выполнить над ресурсом, идентифицируемым URI. Они являются ключевой частью архитектуры RESTful API и имеют строгую семантику, определенную в спецификации HTTP (RFC 7231 и другие). Вот основные различия между наиболее часто используемыми методами.

GET — получение ресурса

• Семантика: Запрос представления указанного ресурса. Должен использоваться только для чтения данных.
• Идемпотентность: Да. Многократные идентичные запросы GET должны возвращать один и тот же результат (если ресурс не изменился).
• Безопасность: Да. Запросы GET не должны изменять состояние сервера.
• Тело запроса: Обычно отсутствует (игнорируется).
• Тело ответа: Присутствует (запрашиваемое представление ресурса).
• Кэширование: Да, по умолчанию кэшируем.
• Использование: Получение HTML-страницы, данных пользователя, списка товаров.

GET /api/users/123 HTTP/1.1
Host: example.com

POST — создание ресурса

• Семантика: Передача данных для обработки целевому ресурсу. Чаще всего используется для создания нового ресурса, когда идентификатор неизвестен или назначается сервером. Также может использоваться для запуска сложных операций (например, отправка формы поиска).
• Идемпотентность: Нет. Многократная отправка одного и того же запроса POST обычно приводит к созданию нескольких ресурсов.
• Безопасность: Нет.
• Тело запроса: Присутствует (данные для создания или обработки).
• Тело ответа: Обычно присутствует (представление созданного ресурса или результат операции). Возвращает код 201 (Created).
• Кэширование: Нет, по умолчанию не кэшируется.
• Использование: Создание нового заказа, регистрация пользователя, отправка комментария.

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "name": "Alice",
  "email": "alice@example.com"
}

PUT — полное обновление/замена ресурса

• Семантика: Полное замещение целевого ресурса представлением из тела запроса. Если ресурс существует — он обновляется. Если не существует — может быть создан (хотя это зависит от реализации API). Клиент должен знать полный URI ресурса.
• Идемпотентность: Да. Многократные одинаковые запросы PUT приводят к одному и тому же состоянию ресурса.
• Безопасность: Нет.
• Тело запроса: Присутствует (полное новое представление ресурса).
• Тело ответа: Может присутствовать (часто пустое). Возвращает 200 (OK) или 204 (No Content) при успешном обновлении, 201 (Created) при создании.
• Использование: Обновление всего профиля пользователя по известному ID.

PUT /api/users/123 HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "name": "Alice Smith", // Полная замена, поле "email" будет удалено, если не передать
  "role": "admin"
}

PATCH — частичное обновление ресурса

• Семантика: Частичное изменение целевого ресурса. Применяет набор изменений, описанных в теле запроса, к существующему ресурсу. Определен в RFC 5789.
• Идемпотентность: Не гарантирована, но должна быть реализована идемпотентно (применение одного патча дважды должно давать тот же результат, что и однократное применение). На практике это зависит от формата патча.
• Безопасность: Нет.
• Тело запроса: Присутствует (инструкции для изменения, например, в формате JSON Patch).
• Тело ответа: Обычно присутствует (обновленное представление ресурса).
• Использование: Обновление только одного поля (например, телефона пользователя).

PATCH /api/users/123 HTTP/1.1
Host: example.com
Content-Type: application/json-patch+json

[
  { "op": "replace", "path": "/email", "value": "new.alice@example.com" }
]

DELETE — удаление ресурса

• Семантика: Удаление указанного ресурса.
• Идемпотентность: Да. Удаление уже удаленного ресурса (при условии, что идентификатор остается недействительным) — это тот же результат (404 Not Found или 410 Gone).
• Безопасность: Нет.
• Тело запроса: Обычно отсутствует (не определено стандартом).
• Тело ответа: Может присутствовать (статус операции) или отсутствовать. Возвращает 200 (OK) с телом, 202 (Accepted) если удаление асинхронное, или 204 (No Content).
• Использование: Удаление статьи, пользователя, файла.

DELETE /api/users/123 HTTP/1.1
Host: example.com

Сводная таблица ключевых свойств

Практическое значение для DevOps

Понимание этих различий критически важно для DevOps-инженера по нескольким причинам:

• Проектирование и документирование API: Участие в обсуждениях о корректном использовании методов для построения предсказуемых и надежных систем.
• Мониторинг и логирование: Анализ логов веб-серверов (Nginx, Apache) и приложений. Аномальное количество POST или DELETE запросов может сигнализировать об атаке или ошибке в клиенте.
• Настройка балансировщиков и брандмауэров (WAF): Правила безопасности и маршрутизации часто настраиваются на основе HTTP-метода. Например, можно разрешить GET-запросы к статике, но строго фильтровать PUT-запросы.
• Кэширование: Знание, что ответы на GET-запросы можно и нужно кэшировать на уровне CDN или обратного прокси (Varnish, Nginx), в то время как POST-запросы — нет.
• Идемпотентность и устойчивость к сбоям: Понимание, что сетевой таймаут на DELETE или PUT запросе допускает безопасный повтор, в отличие от POST. Это влияет на стратегии retry в клиентском коде и настройки очередей сообщений.

Таким образом, HTTP-методы — это не просто техническая деталь, а основа корректного взаимодействия между компонентами распределенной системы, от которой напрямую зависят безопасность, производительность и надежность.