Ответ 201 ничего не доказывает: 20 проверок API, которые ловят ошибки

Базовый запрос — создание заказа с обязательными полями и действующим токеном: товар, количество, адрес доставки. Сервер отвечает 201 Created, заголовком Location с адресом созданного ресурса и телом с идентификатором, составом, статусом и суммой.

По RFC 9110 статус 201 означает, что запрос выполнен и привёл к созданию ресурса. Дальше сценарий разворачивается: после POST заказ запрашивают через GET и сравнивают данные, затем меняют через PATCH, снова читают, удаляют и проверяют, что объект действительно исчез.

Важное правило перед каждым тестом: фиксировать три вещи — исходный запрос, ожидаемый ответ и состояние системы после операции.

Первая группа отвечает на вопрос, правильно ли отработала операция, а не просто вернулся ли ответ.

• Статус-код: совпадает с документацией и не скрывает ошибку в теле ответа.
• Структура ответа: есть все обязательные поля и нет неожиданных.
• Типы и форматы данных: идентификатор, количество, дата создания соответствуют схеме.
• Значения данных: вернулось то, что отправляли, — товар, количество, адрес.
• Бизнес-логика: сумма посчитана по формуле из требований, а не переписана из запроса; статус получил допустимое начальное значение; скидка, доставка, налоги и округление применены в правильном порядке.

Дальше в том же запросе меняют по одному условию за раз. Если убрать сразу и адрес, и товар, непонятно, на что именно ответил сервер.

Проверяют обязательные поля, пустые и null-значения, неверные типы и форматы, граничные и недопустимые значения, лишние и неизвестные поля. Для негативных сценариев мало кода из класса 4xx: ответ должен объяснять причину отказа, указывать на конкретное поле и при этом не раскрывать внутренние детали — трассировку стека, SQL-запрос, путь на диске.

Самая интересная часть начинается там, где заканчивается один ответ. Проверяют запрос без валидной аутентификации, доступ к чужим объектам и разграничение по ролям и функциям.

Затем смотрят на систему целиком: состояние объекта после операции, связанные бизнес-правила и побочные эффекты, повторный запрос и идемпотентность, согласованность связанных эндпоинтов. Пример из разбора: после заказа двух единиц товара остаток должен уменьшиться на два, после отмены — восстановиться, а связанная платёжная или складская операция перейти в правильное состояние.

Отдельно стоит требование к чистоте контракта: в ответе не должно быть хешей паролей, внутренних идентификаторов и чужих адресов почты. OWASP рекомендует ограничивать ответ минимально необходимым набором полей.

Двадцатью пунктами список не заканчивается, набор выбирают по контракту и архитектуре: пагинация, сортировка и фильтрация, ограничение частоты запросов, версионирование и обратная совместимость, конкурентные обновления и оптимистическая блокировка, таймауты и деградация внешних зависимостей, фича-флаги, асинхронные операции со статусом 202 Accepted, вебхуки с подписью и повторами, кэширование с ETag и ответом 304.

Ручная проверка нужна, пока ожидаемый результат ещё уточняется. Когда сценарий стабилизировался, его переносят в коллекцию: base_url и токен выносят в окружение, после создания заказа сохраняют идентификатор в переменную коллекции, следующие запросы обращаются к нему, а проверки живут во вкладке скриптов после ответа.

Collection Runner прогоняет цепочку целиком, а та же коллекция запускается по расписанию или в CI/CD. Автоматизировать имеет смысл только устойчивые проверки: если ожидаемый результат ещё меняется, тест будет ломаться чаще, чем находить ошибки.

Двадцать проверок — это не ритуал, а способ отделить «ответ пришёл» от «система сделала правильно». Половина списка проверяет не ответ, а последствия, и именно там обычно живут дорогие ошибки.