С какими ошибками HTTP-запросов вы чаще всего сталкиваетесь при тестировании API?

При тестировании RESTful и GraphQL API я систематически сталкиваюсь с рядом типичных HTTP-ошибок, которые можно разделить на клиентские (4xx) и серверные (5xx). Их анализ — ключевая часть валидации корректности и отказоустойчивости системы.

Частые клиентские ошибки (4xx):

1. 400 Bad Request: Самая распространенная. Возникает при:

   • Невалидном синтаксисе JSON/XML в теле запроса (пропущена кавычка, запятая).
   • Отсутствии обязательных полей в запросе.
   • Несоответствии типа данных (например, строка "five" вместо числа 5 в поле quantity).

     // Пример запроса, вызывающего 400
     POST /api/products
     {
     "name": "Widget",
     "price": "expensive" // Ожидается число, пришла строка
     }

2. 401 Unauthorized: Проблемы аутентификации. Частая причина — неверный, истекший или отсутствующий токен в заголовке Authorization.

   GET /api/user/profile HTTP/1.1
   Authorization: Bearer expired_token_here

3. 403 Forbidden: Успешная аутентификация, но недостаточно прав. Например, пользователь с ролью USER пытается вызвать эндпоинт, доступный только ADMIN.

4. 404 Not Found: Запрашиваемый ресурс или эндпоинт не существует. Важно отличать логическую 404 (пользователь с ID=999 не найден) от технической (неправильный путь /api/v1/usr вместо /api/v1/user).

5. 409 Conflict: Конфликт при выполнении операции, например, попытка создать пользователя с уже существующим email.

6. 422 Unprocessable Entity (из спецификации WebDAV, но часто используется в API): Синтаксис запроса корректен, но семантически неверен (например, дата рождения в будущем).

7. 429 Too Many Requests: Превышение лимита запросов (Rate Limiting). Критично для тестирования нагрузочных сценариев и проверки корректности возвращаемых заголовков (Retry-After).

Частые серверные ошибки (5xx):

1. 500 Internal Server Error: Общая ошибка сервера. Часто указывает на необработанное исключение в коде бэкенда (NullPointerException, деление на ноль). При тестировании мы стараемся спровоцировать такие ошибки некорректными, но синтаксически верными данными, чтобы проверить граничные условия.

2. 502 Bad Gateway / 503 Service Unavailable / 504 Gateway Timeout: Ошибки, связанные с инфраструктурой — недоступность upstream-сервисов, баз данных, перегрузка балансировщиков. Тестирование отказоустойчивости (chaos testing) часто приводит к таким ответам.

Методика работы с ошибками:

• Валидация тела ошибки: Проверяю, что вместе с кодом статуса возвращается структурированное тело ошибки (обычно JSON) с полями code, message, details, которое поможет разработчику или пользователю понять причину.

  // Ожидаемый формат ошибки
  {
    "error": {
      "code": "VALIDATION_FAILED",
      "message": "Price must be a positive number",
      "field": "price"
    }
  }

• Проверка заголовков: Убеждаюсь, что при ошибках 4xx/5xx также возвращаются корректные заголовки, особенно Content-Type: application/json.
• Логирование: Все такие ошибки должны корректно логироваться на стороне сервера с достаточным контекстом (requestId, userId) для последующего разбора.

Понимание этих ошибок и их причин позволяет не только находить баги, но и оценивать качество дизайна API и его устойчивость к некорректным данным.