Что хотят услышать интервьюеры:

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

Определение:

Проверка структуры переданных данных — это валидация входного payload на соответствие заранее определенному формату. Обычно сервер сверяет, какие поля пришли, какого они типа, есть ли обязательные поля, допустимы ли значения и не нарушены ли ограничения. Для этого используют схемы и валидаторы, например JSON Schema, DTO с аннотациями, middleware или встроенную в фреймворк валидацию.

Пример использования:

Например, API ожидает JSON с полями email и password. Если клиент отправит email без password, сервер вернет ошибку валидации, а не попытается обработать запрос дальше.

{
  "email": "user@example.com",
  "password": "secret123"
}

Если вместо этого придет:

{
  "email": "user@example.com"
}

сервер должен ответить ошибкой, потому что обязательное поле password отсутствует.

Пояснение кода:

Код не требуется. На практике проверка обычно проходит так:

Запрос приходит на сервер.
Тело запроса парсится в объект.
Валидатор сравнивает объект со схемой или DTO.
Если структура не совпадает, сервер возвращает 400 Bad Request или аналогичную ошибку.
Если все корректно, запрос передается в бизнес-логику.

Ключевые моменты:

Проверяется не только наличие полей, но и их типы, формат и ограничения.
Валидация должна выполняться до бизнес-логики.
Часто используются схемы, DTO, аннотации и middleware.
При ошибке сервер обычно возвращает понятное сообщение о том, что именно не так.
Это снижает число падений, багов и некорректных данных в системе.

Каким образом сервер проверяет правильность структуры переданных ему данных?