HTTP-методы, коды статуса и заголовки

HTTP-методы #

HTTP-методы (также называемые глаголами) определяют действие, выполняемое над ресурсом. Глубокое их понимание фундаментально для тестирования API, поскольку использование неправильного метода или тестирование неверного поведения — одна из самых распространённых ошибок.

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

GET-запросы получают данные, не изменяя ничего на сервере. Они и безопасны (без побочных эффектов), и идемпотентны (одинаковый результат независимо от количества вызовов).

GET /api/users HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer <token>

Чек-лист тестирования GET:

• Возвращает 200 OK с данными для существующих ресурсов
• Возвращает 404 Not Found для несуществующих ресурсов
• Никогда не изменяет состояние сервера (проверить БД без изменений после GET)
• Поддерживает фильтрацию через query-параметры
• Возвращает корректную пагинацию для endpoint-ов списков
• Формат ответа соответствует заголовку Accept

POST — Создание новых ресурсов #

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

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer <token>

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

Чек-лист тестирования POST:

• Возвращает 201 Created с новым ресурсом (включая сгенерированный ID)
• Возвращает заголовок Location, указывающий на новый ресурс
• Валидирует обязательные поля (возвращает 400 при отсутствии данных)
• Корректно отклоняет дубликаты (409 Conflict)
• Обрабатывает невалидные типы данных корректно

PUT — Замена ресурса целиком #

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

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

{
  "name": "Alice Smith",
  "email": "alice.smith@example.com",
  "role": "senior-developer"
}

Чек-лист тестирования PUT:

• Заменяет все поля (не включённые поля должны удаляться или устанавливаться в значения по умолчанию)
• Возвращает 200 OK с обновлённым ресурсом или 204 No Content
• Создаёт ресурс, если он не существует (некоторые API возвращают 201)
• Идемпотентен — один и тот же запрос дважды даёт идентичный результат

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

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

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

{
  "role": "senior-developer"
}

Чек-лист тестирования PATCH:

• Обновляет только указанные поля
• Не упомянутые поля остаются без изменений
• Возвращает 200 OK с обновлённым ресурсом
• Корректно обрабатывает невалидные имена полей

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

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

DELETE /api/users/42 HTTP/1.1
Authorization: Bearer <token>

Чек-лист тестирования DELETE:

• Возвращает 204 No Content (или 200 OK с подтверждением)
• Ресурс недоступен после удаления (GET возвращает 404)
• Повторный DELETE того же ресурса возвращает 404 или 204
• Каскадное поведение корректно (связанные ресурсы обработаны правильно)

Менее распространённые методы #

Коды статуса HTTP #

Коды статуса — трёхзначные числа, сообщающие о результате API-запроса. Они организованы в пять классов.

1xx — Информационные #

Редко встречаются в тестировании API:

• 100 Continue — сервер получил заголовки, клиент должен отправить тело
• 101 Switching Protocols — сервер переключается на WebSocket

2xx — Успех #

3xx — Перенаправление #

4xx — Ошибки клиента #

5xx — Ошибки сервера #

HTTP-заголовки #

Заголовки переносят метаданные о запросе или ответе. Это пары ключ-значение, отправляемые вместе с телом.

Основные заголовки запроса #

Authorization — содержит учётные данные аутентификации:

Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0...
Authorization: Basic dXNlcjpwYXNzd29yZA==
Authorization: ApiKey sk-1234567890abcdef

Content-Type — описывает формат тела запроса:

Content-Type: application/json
Content-Type: application/x-www-form-urlencoded
Content-Type: multipart/form-data; boundary=----FormBoundary

Accept — сообщает серверу предпочтительный формат ответа:

Accept: application/json
Accept: application/xml
Accept: text/html, application/json;q=0.9

Основные заголовки ответа #

Content-Type — описывает формат тела ответа:

Content-Type: application/json; charset=utf-8

Cache-Control — директивы кеширования:

Cache-Control: no-cache, no-store, must-revalidate
Cache-Control: public, max-age=3600

Заголовки Rate Limit (нестандартные, но широко используемые):

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 73
X-RateLimit-Reset: 1625097600

Заголовки CORS — Cross-Origin Resource Sharing:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type

Заголовки безопасности для тестирования #

Стратегии тестирования #

Матрица верификации кодов статуса #

Создайте матрицу для каждого endpoint-а, сопоставляя входные данные с ожидаемыми кодами статуса:

Чек-лист тестирования заголовков #

1. Отправить запросы без обязательных заголовков — ожидать 400 или 401
2. Отправить запросы с невалидным Content-Type — ожидать 415 Unsupported Media Type
3. Проверить, что CORS-заголовки разрешают ожидаемые origin-ы
4. Убедиться, что заголовки безопасности присутствуют во всех ответах
5. Проверить точность и согласованность заголовков rate limit
6. Протестировать content negotiation заголовка Accept

Практическое упражнение #

Используя JSONPlaceholder или любой тестовый API:

1. Тестирование методов: Отправьте GET, POST, PUT, PATCH и DELETE на /posts/1. Задокументируйте код статуса и ответ для каждого.
2. Охота за кодами статуса: Найдите запросы, вызывающие минимум 5 разных кодов статуса (200, 201, 204, 404 и ещё один).
3. Инспекция заголовков: Для GET-запроса к /posts перечислите все заголовки ответа и определите, какие относятся к кешированию, типу контента и безопасности.
4. PUT vs PATCH: Обновите пост с помощью PUT (отправляя все поля) и затем с помощью PATCH (отправляя одно поле). Сравните результаты.

Ключевые выводы #

• HTTP-методы определяют действие: GET (чтение), POST (создание), PUT (замена), PATCH (обновление), DELETE (удаление)
• Безопасные методы (GET, HEAD, OPTIONS) никогда не изменяют состояние сервера; идемпотентные методы (GET, PUT, DELETE) дают одинаковый результат при многократном вызове
• Коды статуса сообщают результаты: 2xx успех, 4xx ошибка клиента, 5xx ошибка сервера — каждый код имеет конкретное значение
• Заголовки несут критически важные метаданные: аутентификация, формат контента, кеширование, безопасность и rate limiting
• Систематический подход к тестированию — сопоставление endpoint-ов с ожидаемыми методами, кодами статуса и заголовками — обеспечивает полное покрытие