Какие проверки выполняются при отправке POST-запроса и проверке ответа

Что проверяют

Тестируете ли вы API дальше «пришёл 200»: контракт ответа, побочный эффект, негативные сценарии. Следом часто спрашивают, как вы убедитесь, что запись действительно создалась, и что будет при повторной отправке.

Как отвечать

Идите по порядку от запроса к последствиям:

• запрос: метод, URL, заголовки Content-Type: application/json и Authorization, тело по контракту из OpenAPI;
• статус-код: для создания ресурса обычно 201 Created с заголовком Location, для асинхронной обработки 202, для действия без тела 204. Какой ждать, решает спецификация;
• тело ответа: валидация по JSON Schema, значения совпадают с отправленными, серверные поля вроде id и createdAt на месте и в нужном формате, лишнего нет, например хеша пароля;
• побочный эффект: GET по полученному id возвращает те же данные, запись есть в базе, событие ушло в очередь, если так задумано;
• негативные сценарии: без обязательного поля или с неверным типом 400 либо 422 с понятным текстом, битый JSON 400, чужой Content-Type 415, без токена 401, без прав 403, дубль уникального значения 409;
• граничные значения: максимальная длина строк, пустые строки, юникод и спецсимволы, лишние неизвестные поля;
• повтор: двойная отправка не создаёт дубль, если API обещает идемпотентность, например через ключ идемпотентности в заголовке;
• время ответа: укладывается в требование.

Инструменты назовите свои: Postman с проверками в pm.test, REST Assured, pytest с requests. Хорошо добавить, что эти проверки живут в автотестах и гоняются в CI.

Где спотыкаются

Проверяют только статус и пропускают тело и побочный эффект. Ответ 201 при пустой записи в базе такой тест не поймает.

Считают 500 на некорректный ввод нормальной реакцией. Ошибка клиента должна давать код 4xx, а 500 это баг сервера.

Путают 401 и 403: первый про отсутствующую или невалидную аутентификацию, второй про нехватку прав у известного пользователя.