Какой статус код приходит если ничего не сломалось?

Статус коды HTTP: успешные ответы сервера

В контексте веб-приложений и API тестирования, когда "ничего не сломалось" и операция выполнена успешно, сервер возвращает статус коды из диапазона 2xx (Success). Эти коды указывают, что клиентский запрос был принят, понят и успешно обработан.

Основные успешные статус коды

• 200 OK — самый распространенный и универсальный код успеха. Он означает, что запрос (GET, POST, PUT, DELETE и др.) выполнен успешно, и ответ содержит ожидаемые данные. Например, успешное получение страницы или данных ресурса.

  // Пример ответа с 200 OK для GET /api/users/1
  {
    "status": 200,
    "data": {
      "id": 1,
      "name": "Иван Иванов"
    }
  }
  

• 201 Created — указывает, что запрос (обычно POST или PUT) успешно создал новый ресурс на сервере. Ответ часто содержит заголовок Location с URI нового ресурса.

  HTTP/1.1 201 Created
  Location: /api/tasks/789
  Content-Type: application/json
  
  {"id": 789, "title": "Новая задача", "status": "open"}
  

• 204 No Content — сервер успешно выполнил запрос (часто DELETE или PUT), но не возвращает никакого содержимого в теле ответа. Клиент не должен обновлять свой документ (например, страницу). Это распространенный ответ для операций удаления или обновления, где возвращать данные не требуется.

Почему важно проверять статус коды в QA

Как QA Engineer, я не просто проверяю, что "ничего не сломалось" в общем смысле. Вместо этого я верифицирую, что сервер возвращает корректный и ожидаемый статус код для конкретной операции. Это ключевая часть тестирования API.

• GET запрос к существующему ресурсу должен возвращать 200 OK.
• POST запрос, создающий новый объект, должен возвращать 201 Created.
• DELETE запрос может возвращать либо 200 OK (с сообщением об успехе), либо 204 No Content.
• PUT/PATCH запрос на обновление часто возвращает 200 OK или 204 No Content.

Неправильный статус код — это уже дефект. Например, если после создания пользователя API возвращает 200 вместо 201, это может нарушить логику клиента, который ожидает найти ссылку на новый ресурс в заголовке Location.

Пример проверки в тестовом скрипте

В автоматизированных тестах (например, с использованием Python и библиотеки requests) мы явно проверяем статус код.

import requests
import pytest

def test_create_user_returns_201():
    """Тест проверяет, что успешное создание пользователя возвращает статус 201 Created."""
    url = "https://api.example.com/users"
    new_user_data = {"name": "Тестовый Юзер", "email": "test@example.com"}
    
    response = requests.post(url, json=new_user_data)
    
    # Ключевая проверка: статус код должен быть 201, а не просто "не ошибка"
    assert response.status_code == 201, f"Ожидался 201 Created, получен {response.status_code}"
    
    # Дополнительная проверка: в ответе должен быть ID нового пользователя
    response_data = response.json()
    assert "id" in response_data
    assert response.headers.get("Location") is not None

Таким образом, для QA Engineer ответ на вопрос "какой статус код приходит, если ничего не сломалось?" всегда зависит от конкретного типа HTTP запроса и контекста операции. Мы используем диапазон 2xx кодов как точные индикаторы успеха, и их корректность является обязательным критерием качества работы API. Проверка статус кода — это первый и фундаментальный шаг в тестировании любого веб-интерфейса.