API Lab

Запрос состоит из четырёх частей: метод, URL, заголовки и тело. Ответ — из трёх: статус, заголовки и тело. В нашем сценарии запрос — это POST /api/orders, заголовки Authorization и Content-Type, тело с productId и quantity; ответ — статус 201, заголовки и JSON-тело заказа. Тестировщик проверяет каждую часть отдельно, а не только «пришло что-то с кодом 200».

HTTP-методы выражают намерение. GET — получить данные (без побочных эффектов), POST — создать новый ресурс, PUT — заменить ресурс целиком по id, PATCH — частично обновить поля, DELETE — удалить. Создание заказа — это POST /api/orders: GET не меняет данные, PUT/PATCH работают с уже существующим ресурсом по id, поэтому для создания не подходят.

Статус-коды — это язык сервера. 2xx — успех (200 OK, 201 Created для созданного ресурса, 204 No Content). 4xx — ошибка на стороне клиента (400 Bad Request — кривой запрос, 401 Unauthorized — нет/невалиден токен, 403 Forbidden — токен есть, но прав нет, 404 Not Found, 409 Conflict — конфликт состояния, 422 Unprocessable Entity — данные синтаксически верны, но не проходят бизнес-валидацию). 5xx — вина сервера (500 Internal Server Error, 502/503/504). QA сверяет фактический статус с ожидаемым по контракту, а не радуется любому 200.

Заголовки несут метаданные. Content-Type: application/json объявляет формат тела — без него сервер может не распарсить JSON и вернуть 415/400. Authorization: Bearer <token> передаёт токен доступа; его отсутствие или истечение должно давать 401, а доступ к чужому ресурсу с валидным токеном — 403/404. Тестировщик проверяет и Request-заголовки (что отправили), и Response-заголовки (что вернули).

JSON-схема на уровне QA — это контракт тела ответа: какие поля есть, какого они типа и какие обязательны. Для нашего ответа: orderId (строка, обязательно), status (строка, обязательно, ожидается 'created'), totalAmount (число, обязательно), currency (строка, обязательно). Проверка контракта — это не «есть ли вообще тело», а «есть ли все обязательные поля, верных ли они типов, нет ли лишнего/null там, где ожидается значение».

Обязательные и опциональные поля проверяют отдельно. По каждому обязательному полю запроса нужен негативный кейс: «что вернёт сервер, если поля нет, оно пустое, null или неверного типа». Корректный сервер на отсутствие productId или quantity отвечает 400/422 с понятным описанием, а не 500 и не «молчаливым» 201 с битым заказом. Опциональные поля проверяют на поведение по умолчанию.

Негативное тестирование и идемпотентность. Кроме «счастливого пути» проверяют невалидные данные (quantity = 0 или -1, неизвестный productId), отсутствие авторизации, конфликты. Идемпотентность означает: повторный одинаковый запрос не меняет результат сверх первого. GET/PUT/DELETE идемпотентны по определению, POST — нет, поэтому повторный POST создания заказа без защиты (Idempotency-Key) может создать дубль. Идемпотентность проверяют по реальному состоянию (сколько заказов создалось), а не по коду ответа.

Безопасные сообщения об ошибках и API-evidence. Тело ошибки должно помогать клиенту («поле quantity должно быть > 0»), но не раскрывать внутренности (стек-трейсы, SQL, секреты, существование пользователя). API-evidence для баг-репорта — это полный запрос (метод, URL, заголовки без секретов, тело), фактический ответ (статус + тело) и ожидаемый по контракту. Формула: «отправил такой запрос → получил такой ответ → ожидался такой». Это делает дефект воспроизводимым одной командой curl/Postman.