🧭 Refactor: переход на Pydantic модели в API
📌 Цель
Упорядочить структуру ответов всех основных API-роутов за счёт использования Pydantic моделей, сократить ручную сериализацию и повысить читаемость и предсказуемость контрактов для фронтенда.
Рефактор не должен менять бизнес-логику — только способ формирования и валидации ответов.
📝 Описание
Сейчас каждый роут возвращает данные в виде «сырых» словарей, собранных вручную. Это:
- усложняет поддержку;
- затрудняет расширение схемы (например, добавление новых полей);
- не даёт нормальной OpenAPI-документации;
- не позволяет использовать статическую типизацию и автогенерацию SDK.
Переход на Pydantic:
- стандартизирует ответы между модулями;
- улучшит автогенерацию схем и документации;
- упростит тестирование;
- снизит количество дублированного кода.
📅 План работ
✅ Ожидаемый результат
- Все ключевые роуты возвращают данные через Pydantic модели.
- Документация
/docs полностью соответствует актуальной схеме ответов.
- Поддержка новых полей и изменений структуры в дальнейшем требует минимальных правок.
- Код становится чище, понятнее и проще для ревью и тестирования.
🧭 Refactor: переход на Pydantic модели в API
📌 Цель
Упорядочить структуру ответов всех основных API-роутов за счёт использования Pydantic моделей, сократить ручную сериализацию и повысить читаемость и предсказуемость контрактов для фронтенда.
Рефактор не должен менять бизнес-логику — только способ формирования и валидации ответов.
📝 Описание
Сейчас каждый роут возвращает данные в виде «сырых» словарей, собранных вручную. Это:
Переход на Pydantic:
📅 План работ
modelsдля Pydantic схем.task,customer,inventory,attachs,employee,ont,box,addata) наresponse_model.response_model_exclude_none=Trueдля чистых ответов.✅ Ожидаемый результат
/docsполностью соответствует актуальной схеме ответов.