Ваш endpoint получает
age из request body и прибавляет к нему 1. Месяцами всё работает нормально. А затем client отправляет age как "twenty", и необработанный TypeError приводит к ошибке где-то глубоко внутри приложения — далеко от handler, который изначально получил request.Валидируйте данные на входе, а не внутри business logic.
Request body — это недоверенные входные данные. Schema явно определяет, что именно принимает приложение: названия полей, типы данных, ограничения и обязательные значения.
Валидные данные попадают в приложение как проверенный, строго типизированный object. Невалидные сразу отклоняются на HTTP boundary с
422 Unprocessable Content или 400 Bad Request.Без schema каждой downstream function приходится самостоятельно перепроверять входные данные. И первая функция, которая забудет это сделать, может стать причиной следующего production incident.
Есть два важных поведения, о которых стоит знать при работе с Pydantic или serializers вашего framework.
Первое — coercion. По умолчанию
"123" может превратиться в 123: строка незаметно преобразуется в объявленный тип. Это удобно, но может скрыть ошибку client, который отправляет данные неправильного типа. Strict mode отключает такое поведение.Второе — extra fields. Необъявленное поле может быть молча отброшено без ошибки. Например, если отправить
is_admin в schema, где такого поля нет, оно просто исчезнет. Но если raw input затем попадёт напрямую в model, принятие лишних полей может стать уязвимостью. Настройка extra='forbid' позволяет отклонять такие данные.Парсите и валидируйте данные один раз на входе, чтобы core logic работала только с теми структурами данных, для которых она была создана.
👉 @BackendPortal