Почему сервер может вернуть четырёхсотый статус код?

Почему сервер может вернуть четырёхсотый статус код?

В контексте HTTP-протокола, четырехсотые статусные коды (400-499) обозначают ошибки клиента (Client Error). Они указывают, что проблема возникла из-за некорректного запроса, отправленного с клиентской стороны (например, браузера, мобильного приложения или другого клиентского ПО). Сервер, получивший такой запрос, не может или не хочет его обработать и возвращает соответствующий код, объясняющий причину. Эти коды являются важным инструментом для диагностики проблем в веб-приложениях и API.

Основные причины возврата четырёхсотых кодов

1. Неверная структура или синтаксис запроса (400 Bad Request)

Это самый распространённый код. Сервер не может понять запрос из-за:

• Некорректный формат JSON или XML в теле запроса.
• Неверная структура заголовков (headers).
• Проблемы с кодированием (encoding).

// Пример плохого JSON, который может вызвать 400 Bad Request
{
  "username": "John",
  "age: 30  // Ошибка: пропущена закрывающая кавычка и запись некорректна
}

2. Проблемы с аутентификацией и авторизацией (401 Unauthorized, 403 Forbidden)

• 401 Unauthorized: Клиент не предоставил необходимые credentials (например, токен, пароль) или предоставил неверные.
• 403 Forbidden: Сервер понял запрос, но отказывает в доступе, даже если клиент аутентифицирован (нет прав).

3. Конфликт или невозможность выполнения условия (409 Conflict, 412 Precondition Failed)

• 409 Conflict: Запрос конфликтует с текущим состоянием ресурса (например, попытка обновить данные, которые уже изменились).
• 412 Precondition Failed: Условия, заданные в заголовках запроса (например, If-Match), не выполняются.

4. Ошибки в условиях запроса или несуществующие ресурсы (404 Not Found, 405 Method Not Allowed)

• 404 Not Found: Сервер не нашёл запрашиваемый ресурс (URL). Это может быть ошибка в ссылке, удалённый ресурс или неверный маршрут в API.
• 405 Method Not Allowed: Используемый HTTP-метод (GET, POST, PUT) не разрешён для данного URL.

5. Ошибки валидации данных или размеров (422 Unprocessable Entity, 413 Payload Too Large)

• 422 Unprocessable Entity (часто в REST API): Тело запроса корректно с синтаксической точки зрения, но содержит логические ошибки или не проходит бизнес-валидацию (например, отрицательный возраст).
• 413 Payload Too Large: Размер тела запроса (например, файла для загрузки) превышает лимиты сервера.

С точки зрения тестирования (QA)

Для QA Engineer понимание этих кодов критично для:

• Написания тест-кейсов на негативные сценарии.
• Анализа логов и результатов тестов.
• Взаимодействия с разработчиками при обнаружении багов.

При тестировании API, например, мы должны проверить:

• Возврат 400 Bad Request при отправке битого JSON.
• Возврат 401 Unauthorized при запросе без токена к защищённому эндпоинту.
• Возврат 404 Not Found при попытке доступа к несуществующему ID ресурса.
• Возврат 422 Unprocessable Entity при отправке данных, нарушающих бизнес-правила (например, email в неправильном формате).

# Пример теста на 400 Bad Request для API
import requests

def test_bad_request():
    url = "https://api.example.com/users"
    # Создаем запрос с явно некорректным JSON
    bad_json = '{"name": "test", "age": }'  # Неполная структура
    headers = {'Content-Type': 'application/json'}
    
    response = requests.post(url, data=bad_json, headers=headers)
    
    assert response.status_code == 400
    # Также часто проверяем, что в ответе есть описание ошибки
    assert "error" in response.json()
    print("Тест на 400 Bad Request пройден.")

В заключение, четырёхсотые статусные коды — это четкие сигналы от сервера о том, что клиент должен исправить свой запрос. Они помогают строить более устойчивые клиентские приложения и являются ключевым элементом контракта между клиентом и сервером в веб-разработке. Для QA их анализ — прямая дорога к обнаружению дефектов в логике клиента или в документации API.