Как в Python реализовать валидацию данных и обработку ошибок на стороне бэкенда

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

Популярные инструменты:

1. Pydantic (особенно в FastAPI) Pydantic использует аннотации типов Python для определения схем данных. FastAPI автоматически интегрируется с Pydantic, выполняя валидацию "из коробки" и возвращая стандартизированные ошибки.

   # Используется в FastAPI
   from fastapi import FastAPI
   from pydantic import BaseModel, EmailStr, Field
   
   app = FastAPI()
   
   class UserCreate(BaseModel):
       email: EmailStr
       age: int = Field(gt=18, description="Возраст должен быть больше 18")
   
   @app.post("/users/")
   def create_user(user: UserCreate):
       return {"status": "ok", "email": user.email}
   
   # При неверных данных FastAPI автоматически вернет 422 ошибку с JSON
   # {"detail":[{"loc":["body","age"],"msg":"ensure this value is greater than 18", ...}]}

2. Marshmallow Популярная библиотека для сериализации/десериализации и валидации объектов. Часто используется с Flask и Django.

   from marshmallow import Schema, fields, ValidationError
   
   class UserSchema(Schema):
       email = fields.Email(required=True)
       age = fields.Int(validate=lambda n: n > 18)
   
   def create_user_view(request_data):
       try:
           data = UserSchema().load(request_data)
           # ... логика создания пользователя
           return {"status": "ok"}, 201
       except ValidationError as err:
           # Возвращаем словарь с ошибками для каждого поля
           return {"errors": err.messages}, 400

Ключевые принципы:

• Стандартизированный формат ошибок: API должен всегда возвращать ошибки в единой структуре (например, {"errors": {"field_name": ["error message"]}}), чтобы клиент мог их единообразно обрабатывать.
• Корректные HTTP-статусы: Используйте 400 Bad Request для общих ошибок запроса и 422 Unprocessable Entity для ошибок валидации данных.
• Четкие сообщения об ошибках: Сообщения должны быть понятны разработчику клиента (а иногда и конечному пользователю).
• Разделение логики: Логика валидации должна быть инкапсулирована в схемах или классах данных, а не разбросана по коду обработчиков запросов.