HTTP-методы: GET, POST, PUT, DELETE и другие

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

Обзор HTTP-методов

Метод	Назначение	Тело запроса	Безопасный	Идемпотентный	Кэшируемый
GET	Получить ресурс	Нет	Да	Да	Да
POST	Создать ресурс или выполнить действие	Да	Нет	Нет	Редко
PUT	Полностью заменить ресурс	Да	Нет	Да	Нет
PATCH	Частично обновить ресурс	Да	Нет	Нет*	Нет
DELETE	Удалить ресурс	Опционально	Нет	Да	Нет
HEAD	Как GET, но без тела ответа	Нет	Да	Да	Да
OPTIONS	Описать параметры взаимодействия	Нет	Да	Да	Нет

Безопасный — метод не изменяет состояние сервера. Идемпотентный — многократный вызов даёт тот же результат, что и однократный. *PATCH может быть идемпотентным в зависимости от реализации.

GET — получение данных

GET-запросы извлекают данные с сервера без их модификации. Это самый распространённый HTTP-метод — загрузка веб-страниц, получение данных API, скачивание файлов.

GET /api/v1/users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGci...

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60

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

Ключевые правила GET:

• Никогда не используйте GET для изменения данных — это нарушает семантику HTTP и создаёт риски безопасности
• GET-запросы должны быть кэшируемыми и сохраняемыми в закладки
• Параметры передаются в строке запроса URL, а не в теле запроса
• URL имеют практические ограничения длины (2048 символов во многих браузерах)

POST — создание или действие

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

POST /api/v1/users HTTP/1.1
Content-Type: application/json

{"name": "Bob", "email": "bob@example.com"}

HTTP/1.1 201 Created
Location: /api/v1/users/43

{"id": 43, "name": "Bob", "email": "bob@example.com"}

Типичные применения:

• Создание новых ресурсов (пользователи, заказы, публикации)
• Отправка форм
• Загрузка файлов
• Запуск процессов (отправка писем, генерация отчётов)
• Любые неидемпотентные операции

PUT — полная замена

PUT заменяет весь ресурс по указанному URL данными из тела запроса. PUT идемпотентен — многократная отправка одного PUT имеет тот же эффект, что и однократная.

PUT /api/v1/users/43 HTTP/1.1
Content-Type: application/json

{"id": 43, "name": "Bob Smith", "email": "bob.smith@example.com", "role": "admin"}

HTTP/1.1 200 OK

Важно: PUT заменяет ресурс целиком. Если поле не указано, оно должно быть удалено или установлено в значение по умолчанию. Это отличается от PATCH, который обновляет только указанные поля.

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

PATCH применяет частичные модификации к ресурсу. Обновляются только поля, включённые в тело запроса; остальные остаются без изменений.

PATCH /api/v1/users/43 HTTP/1.1
Content-Type: application/json

{"role": "admin"}

HTTP/1.1 200 OK

{"id": 43, "name": "Bob", "email": "bob@example.com", "role": "admin"}

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

DELETE удаляет ресурс по указанному URL. Он идемпотентен — удаление уже удалённого ресурса должно возвращать успех (или 404), а не ошибку.

DELETE /api/v1/users/43 HTTP/1.1
Authorization: Bearer eyJhbGci...

HTTP/1.1 204 No Content

HEAD — только метаданные

HEAD идентичен GET, но сервер не возвращает тело ответа. Используется для проверки существования ресурса, валидации кэша или получения заголовков без загрузки содержимого.

HEAD /large-file.zip HTTP/1.1
Host: cdn.example.com

HTTP/1.1 200 OK
Content-Length: 524288000
Content-Type: application/zip
Last-Modified: Mon, 15 Jan 2024 10:30:00 GMT

Применения HEAD:

• Проверка доступности URL (мониторинг аптайма)
• Получение размера файла перед загрузкой
• Проверка актуальности кэша с If-None-Match или If-Modified-Since
• Проверка цепочек редиректов без загрузки контента

OPTIONS — возможности взаимодействия

OPTIONS описывает доступные параметры взаимодействия для ресурса. Чаще всего встречается в предварительных CORS-запросах:

OPTIONS /api/v1/users HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Access-Control-Request-Method: POST

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

PUT vs PATCH: когда что использовать

Сценарий	Метод	Обоснование
Полная замена профиля пользователя	PUT	Устанавливаются все поля
Обновление только email	PATCH	Меняется одно поле
Загрузка полного файла конфигурации	PUT	Весь ресурс заменяется
Переключение флага функции	PATCH	Изменение одного поля
Upsert (создание или замена)	PUT	Клиент указывает полный ресурс

HTTP-методы в мониторинге

Для веб-мониторинга HTTP-методы имеют конкретные применения:

• HEAD для проверки аптайма — используйте HEAD вместо GET для минимизации трафика и побочных эффектов
• GET для проверки контента — когда нужно валидировать содержимое ответа, а не только доступность
• OPTIONS для тестирования CORS — проверка корректности политик кросс-доменного доступа
• Коды ответов важны — 405 Method Not Allowed указывает, что эндпоинт существует, но не поддерживает используемый метод

Лучшие практики проектирования API

• Используйте правильный метод для каждой операции — не применяйте POST для всего
• Возвращайте корректные статус-коды: 200 (OK), 201 (Created), 204 (No Content), 404 (Not Found), 405 (Method Not Allowed)
• Обеспечивайте реальную идемпотентность — повтор PUT или DELETE должен быть безопасным
• Включайте заголовок Location в ответы 201 для указания на созданный ресурс
• Поддерживайте HEAD для каждого GET-эндпоинта

Итоги

HTTP-методы обеспечивают чёткую семантику взаимодействия клиента и сервера. Их правильное использование — GET для чтения, POST для создания, PUT для замены, PATCH для частичных обновлений, DELETE для удаления, HEAD для метаданных и OPTIONS для описания возможностей — приводит к предсказуемым, кэшируемым и поддерживаемым API. Понимание свойств безопасности и идемпотентности необходимо для построения надёжных веб-сервисов и эффективного мониторинга.