Гарантирует ли ответ 200, что запрос работает?

Гарантирует ли статус-код 200 корректность работы запроса?

Нет, HTTP-статус 200 OK не гарантирует, что запрос работает корректно с точки зрения бизнес-логики приложения. Он лишь указывает на то, что сервер успешно принял, обработал запрос и вернул какой-то ответ, не обнаружив технических ошибок на уровне протокола (например, проблем с синтаксисом запроса, авторизацией или доступом к ресурсу). Однако корректность самого ответа, его содержимого и соответствия ожиданиям необходимо проверять отдельно.

Почему ответ 200 — недостаточный критерий

Ответ 200 OK — это сигнал от транспортного уровня, но он не даёт информации о смысловом (семантическом) уровне данных. Вот ключевые аспекты, которые необходимо валидировать помимо статус-кода:

1. Структура и тип данных (Data Schema/Contract). Сервер может вернуть 200 с ответом в неожиданном формате.

   // Ожидаемая структура
   {
     "id": 123,
     "name": "Product Name"
   }
   
   // Фактический ответ (статус 200, но нет обязательного поля)
   {
     "productId": 123,
     "title": "Product Name"
   }
   

    Для проверки используются **схемы (JSON Schema, XML Schema)** или строгие сравнения с эталонными моделями.

1. Корректность данных (Business Logic). Данные могут быть структурно верными, но логически ошибочными.

   // Запрос: GET /api/products?category=books
   // Ответ 200, но данные не соответствуют фильтру
   {
     "products": [
       { "id": 1, "name": "Laptop", "category": "electronics" },
       { "id": 2, "name": "Novel", "category": "books" }
     ]
   }
   

    Здесь необходим анализ содержимого на соответствие условиям запроса.

1. Состояние системы (State). Запрос может формально выполниться (200), но не оказать ожидаемого воздействия на систему.

    *   `POST /api/users` → `200`, но пользователь не создался в БД.
    *   `PUT /api/orders/status` → `200`, но статус заказа не изменился.
    *   **Рекомендация:** После модифицирующих запросов (POST, PUT, DELETE) выполнять проверочный `GET`-запрос для подтверждения изменений.

1. Заголовки ответа (Headers). Важны для безопасности, кэширования, типа контента.

   HTTP/1.1 200 OK
   Content-Type: text/html # Ожидался application/json
   

    Отсутствие заголовка `Content-Type: application/json` или `Cache-Control` может привести к ошибкам на клиенте.

1. Производительность (Performance). Ответ 200 может прийти с неприемлемой задержкой. Необходимо проверять время отклика (response time) и устанавливать SLA (Service Level Agreements) пороги.

2. Ошибки внутри тела ответа (Embedded Errors). Некоторые API всегда возвращают 200, а об ошибках сигнализируют внутри JSON/XML.

   {
     "status": "error",
     "message": "Insufficient funds"
   }
   

    Требуется парсинг и анализ поля `status`.

Практический подход для QA Automation

В автоматизированных тестах проверка должна быть комплексной:

import pytest
import requests
from jsonschema import validate

# Определение схемы ответа
PRODUCT_SCHEMA = {
    "type": "object",
    "properties": {
        "id": {"type": "integer"},
        "name": {"type": "string"},
        "price": {"type": "number", "minimum": 0}
    },
    "required": ["id", "name"]
}

def test_get_product_returns_valid_data():
    # 1. Выполнение запроса
    response = requests.get('https://api.example.com/products/1')

    # 2. Проверка статус-кода (базовая, обязательная проверка)
    assert response.status_code == 200, f"Expected 200, got {response.status_code}"

    # 3. Проверка заголовка Content-Type
    assert response.headers['Content-Type'] == 'application/json'

    # 4. Парсинг JSON
    response_data = response.json()

    # 5. Валидация структуры ответа по схеме (JSON Schema)
    validate(instance=response_data, schema=PRODUCT_SCHEMA)

    # 6. Проверка бизнес-правил (семантическая корректность данных)
    assert response_data['id'] == 1
    assert response_data['price'] > 0  # Цена должна быть положительной

    # 7. (Опционально) Проверка производительности
    assert response.elapsed.total_seconds() < 1.0  # Ответ менее чем за 1 секунду

    # 8. (Для модифицирующих запросов) Доп. проверка через GET
    # ... Код для POST/PUT/DELETE запросов ...

Вывод

HTTP 200 — необходимый, но недостаточный критерий успешности. Для гарантии корректной работы API необходим многоуровневый подход к валидации, включающий:

• Проверку статус-кода.
• Валидацию заголовков.
• Проверку соответствия ответа контракту (схеме).
• Верификацию бизнес-логики и корректности данных.
• Мониторинг времени ответа.
• Для операций изменения данных — подтверждение изменений в системе (через последующие запросы).

Только такой комплексный подход позволяет утверждать, что «запрос работает» не только технически, но и функционально.