Какие знаешь основные статус-коды HTTP?

Основные группы и статус-коды HTTP

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

1xx: Информационные (Informational)

Эти коды указывают на промежуточный статус обработки запроса. В практике автоматизации веб-UI или API тестирования встречаются редко, но важно знать их существование.

• 100 Continue — Сервер получил заголовки запроса и готов принять тело. Клиент может продолжать отправку.
• 101 Switching Protocols — Сервер соглашается сменить протокол, например, перейти с HTTP на WebSocket.

2xx: Успех (Success)

Наиболее желаемая группа в тестах. Говорит о том, что запрос был успешно получен, понят и обработан.

• 200 OK — Стандартный ответ на успешные GET, PUT, POST или DELETE запросы. В REST API это основной код для успешного получения данных (GET) или их обновления (PUT/PATCH).
• 201 Created — Запрос успешен и в результате был создан новый ресурс (часто в ответ на POST). В ответе обычно должен быть заголовок Location с URI нового объекта.
• 202 Accepted — Запрос принят на обработку, но она еще не завершена (асинхронные операции).
• 204 No Content — Сервер успешно обработал запрос, но не возвращает никакого контента в теле ответа. Частый код для успешных DELETE операций или некоторых POST/PUT, где ответ с данными не нужен.

3xx: Перенаправление (Redirection)

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

• 301 Moved Permanently — Ресурс навсегда перемещен на новый URI. Браузеры и клиенты обычно кэшируют этот редирект и в дальнейшем обращаются сразу к новому адресу.
• 302 Found (или Moved Temporarily) — Ресурс временно доступен по другому URI. Последующие запросы должны использовать старый адрес.
• 304 Not Modified — Используется для кэширования. Сервер сообщает клиенту, что запрашиваемый ресурс не изменялся с момента последнего запроса, и клиент может использовать свою кэшированную версию.

4xx: Ошибка клиента (Client Error)

Означает, что запрос содержит ошибку и сервер не может (или не должен) его обработать. В автотестах мы часто ожидаем эти коды для проверки негативных сценариев.

• 400 Bad Request — Общая ошибка из-за некорректного синтаксиса запроса (например, невалидный JSON в теле POST-запроса).
• 401 Unauthorized — Требуется аутентификация. Клиент не предоставил или предоставил неверные учетные данные.
• 403 Forbidden — Сервер понял запрос, но отказывается его авторизовать. Доступ запрещен, даже если клиент аутентифицирован (нет прав).
• 404 Not Found — Самый известный код. Сервер не может найти запрошенный ресурс. В API-тестировании — частый ответ на запрос к несуществующему endpoint или объекту с неверным ID.
• 405 Method Not Allowed — Метод запроса (GET, POST и т.д.) не поддерживается для данного URI.
• 409 Conflict — Запрос конфликтует с текущим состоянием сервера (например, попытка создать дублирующий ресурс с уникальным полем).
• 429 Too Many Requests — Клиент отправил слишком много запросов за короткое время (rate limiting). Критически важно при тестировании нагрузочных сценариев и лимитов API.

5xx: Ошибка сервера (Server Error)

Группа фатальных ошибок. Указывает, что сервер не смог обработать валидный запрос из-за внутренней ошибки. Это прямые кандидаты на баг-репорты.

• 500 Internal Server Error — Общая, "универсальная" ошибка сервера. Произошло что-то непредвиденное, что не позволяет выполнить запрос.
• 502 Bad Gateway — Сервер, выступая в роли шлюза или прокси, получил неверный ответ от вышестоящего сервера.
• 503 Service Unavailable — Сервер временно не может обработать запрос из-за перегрузки или технического обслуживания. Часто сопровождается заголовком Retry-After.
• 504 Gateway Timeout — Сервер, выступая в роли шлюза или прокси, не дождался ответа от вышестоящего сервера в отведенное время.

Пример использования в автотестах (на Python с pytest и requests)

import requests
import pytest

BASE_URL = "https://api.example.com"

def test_get_resource_success():
    """Позитивный сценарий: получение существующего ресурса."""
    response = requests.get(f"{BASE_URL}/users/1")
    assert response.status_code == 200  # Ожидаем успех
    data = response.json()
    assert data['id'] == 1
    assert 'name' in data

def test_create_resource():
    """Позитивный сценарий: создание ресурса."""
    payload = {"name": "John Doe"}
    response = requests.post(f"{BASE_URL}/users", json=payload)
    assert response.status_code == 201  # Ожидаем код создания
    assert 'Location' in response.headers  # Проверяем заголовок с ссылкой

def test_get_nonexistent_resource():
    """Негативный сценарий: запрос несуществующего ресурса."""
    response = requests.get(f"{BASE_URL}/users/99999")
    assert response.status_code == 404  # Ожидаем ошибку 'Not Found'

def test_bad_request_invalid_json():
    """Негативный сценарий: отправка некорректных данных."""
    headers = {'Content-Type': 'application/json'}
    # Отправляем невалидный JSON
    response = requests.post(f"{BASE_URL}/users", data="{invalid json", headers=headers)
    assert response.status_code == 400  # Ожидаем ошибку 'Bad Request'

Понимание этих кодов позволяет QA Automation инженеру не только валидировать сценарии, но и грамотно проектировать проверки, точно интерпретировать логи и эффективно коммуницировать с разработчиками при анализе сбоев.