Как сервис должен реагировать на некорректные параметры запроса
Что проверяют
Знаете ли вы, какое поведение считать правильным, и умеете ли проверить его не только по коду ответа. Следом обычно просят составить набор негативных проверок для конкретного эндпоинта или спрашивают, чем 400 отличается от 422.
Как отвечать
Сначала ожидаемое поведение, на которое опирается тестировщик:
- код 4xx, а не 500: ошибка клиента не должна превращаться в ошибку сервера.
400 Bad Requestдля синтаксически битого запроса (невалидный JSON, строка вместо числа),422 Unprocessable Contentтам, где команда договорилась отделять смысловую валидацию,404для несуществующего ресурса в пути,415для чужогоContent-Type,413для слишком большого тела; - понятное тело ошибки: какое поле и что с ним не так. Хороший ориентир RFC 9457 (Problem Details), тип
application/problem+jsonс полямиtype,title,status,detail; - без утечек: в ответе нет стектрейса, SQL, внутренних путей и версий библиотек;
- без побочных эффектов: запрос отклонён целиком, запись в базе не появилась, письмо не ушло.
Затем покажите, как это проверяете. Опора на контракт (OpenAPI), дальше классы эквивалентности и граничные значения: пропущенный обязательный параметр, null, пустая строка, неверный тип, значение за границей диапазона, очень длинная строка, спецсимволы и Unicode, лишние неизвестные поля, дублирующийся параметр в query. Инструменты: Postman или Bruno для ручной проверки, REST Assured или pytest с requests для автотестов, проверка тела ответа по JSON Schema. После каждого негативного запроса стоит проверить состояние: через GET или прямо в базе.
Где спотыкаются
Проверяют только код ответа. 400 пришёл, а в теле пусто или ошибка про другое поле, и клиент API не поймёт, что исправить.
Принимают 500 как «ну ошибка же». Это баг: сервис упал на входных данных, и в логах обычно лежит необработанное исключение.
Спорят о 400 против 422 без контракта. Оба варианта встречаются, важнее единообразие по всем эндпоинтам и совпадение с документацией, а расхождение между ними и есть дефект.