HTTP-запрос, ответ и проверяемый контракт
Разберите метод, адрес, заголовки и тело; соберите ожидание шире одного статуса.
- Читать запрос и ответ как набор независимых частей.
- Получать ожидания из конкретной версии контракта.
- Проверять статус, заголовки, данные и побочный эффект.
API — наблюдаемая граница системы
HTTP-запрос задаёт метод, целевой ресурс, заголовки и при необходимости тело. Ответ даёт статус, заголовки и представление результата. URL выбирает объект или действие, а данные JSON являются содержимым, не частью самого метода. Эти слои можно нарушить независимо: правильный URL с отсутствующим токеном; корректный JSON с неверным типом поля; успешный статус с неправильным автором в теле. Поэтому тест API начинается с контракта, а не с нажатия Send.
В нашем стенде Bearer demo-anna задаёт синтетического участника north, а не значение authorId из тела запроса. Клиент не может назначить автора через неизвестное поле: A2 требует отказ. Этот выбор нужен для учебной проверки доверия к входным данным. В другом API поля и правила будут иными. Сначала откройте согласованную спецификацию нужной версии; привычная форма REST не даёт права выдумывать обязательные поля или статус.
Успех проверяется целиком
Для POST /tasks с {"title":"План"} A3 обещает 201 и Location, указывающий на новый ID, а также draft, автора из токена и defaults description="", priority=normal. Проверка только 2xx пропустит 200 вместо 201, неверное состояние или подмену автора. Точная проверка текста title нужна, чтобы заметить скрытый trim. Отдельный GET новым ID под тем же автором подтверждает читаемое сохранение; лабораторный snapshot позволяет проверить, что создана ровно одна запись.
Не привязывайте будущий тест к ожидаемому t5, даже если после reset этот ID вероятен. Возьмите фактический ID из успешного ответа, проверьте его тип и непустоту, затем используйте в следующих шагах. Сравните Location с этим же ID. Так тест выражает правило идентичности, а не случайное значение счётчика. Подобная зависимость особенно важна при параллельном выполнении и повторных запусках.
HTTP-семантика и правило продукта — разные основания
Классы статусов помогают ориентироваться: 2xx означает успешный результат на уровне операции, 4xx сообщает о проблеме запроса в рамках выбранной семантики. Но точный ответ на недостаточные права, скрытый объект или повторную публикацию устанавливает API-CORE-1. Порядок 401→404→403→409→422 в A5 не является универсальным правилом HTTP. Если в реальном проекте контракт возвращает 403 вместо скрывающего 404, тест должен следовать тому контракту.
Наша лаборатория моделирует требуемое поведение и даёт воспроизводимую практику клиента. Успешный прогон доказывает соответствие этой локальной модели проверенным сценариям. Он ничего не сообщает о безопасности production-портала, реальной базе, шифровании или распределённых сбоях. При офлайн-анализе исходных трасс укажите «проанализировано», а динамический статус новых запросов оставьте Not run до фактического запуска.
Первый запрос в локальный стенд
curl -i http://127.0.0.1:4177/tasks \
-H 'Authorization: Bearer demo-anna' \
-H 'Content-Type: application/json' \
--data '{"title":"План"}'Источники и проверка фактов
RFC 9110 — HTTP SemanticsСемантика методов и статусов. Порядок проверок и поля OrbitDesk заданы отдельным учебным контрактом, не самим HTTP.OpenAPI Specification 3.1.1Структура описания операций, параметров, запросов и ответов; в курсе зафиксирована конкретная версия документа, не заявлена последней.Авторский учебный материал · Редакция QA Orbit · версия 2026-10-28.1