Что такое валидация сообщений в REST

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

Умеете ли вы задать контракт так, чтобы правила проверки были описаны в требованиях, а не додуманы разработчиком по дороге. Аналитику этот вопрос задают как проверку на полноту постановки и на знание кодов ответа.

Как отвечать

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

Дальше скажите, где это живёт. Первый уровень место схемы: спецификация OpenAPI с JSON Schema и есть машиночитаемый контракт, по ней генерируются проверки и тесты. Второй и третий описываются в требованиях вместе с кодом ошибки и текстом для пользователя.

Коды ответа проговорите явно: нарушение схемы это 400, синтаксически верный, но недопустимый по смыслу запрос обычно 422, конфликт состояния 409, ссылка на несуществующий ресурс 404. Ответ 200 с описанием ошибки внутри тела это антипаттерн.

Отдельно опишите единый формат ошибки: машинный код, имя поля, сообщение, и возврат сразу всего списка нарушений, а не первого найденного.

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

Ограничиваются фразой про обязательные поля. Нет границ, форматов, поведения на лишние и неизвестные поля, нет правила про регистр и пробелы, и каждый разработчик решает это по-своему.

Считают, что проверок на клиенте достаточно. Запрос уходит мимо интерфейса из любого консольного клиента, поэтому серверная проверка обязательна, а клиентская существует ради удобства.

Отдают в тексте ошибки внутренние подробности: имя таблицы, фрагмент запроса, стек вызовов. Это одновременно подсказка атакующему и утечка устройства системы, а пользователю такое сообщение ничего не объясняет.