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

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

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

Безопасный — метод не изменяет состояние сервера. Идемпотентный — многократный вызов даёт тот же результат, что и однократный. *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: когда что использовать

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. Понимание свойств безопасности и идемпотентности необходимо для построения надёжных веб-сервисов и эффективного мониторинга.