Основы FastAPI и проектирование API
Тема дорожной карты · Python Programming
FastAPI — асинхронный web-фреймворк на базе Starlette и Pydantic, который превращает type hints в валидацию запросов, сериализацию и документацию OpenAPI. Бери его, когда нужен типизированный REST или streaming API без лишних церемоний; для синхронной CPU-нагрузки проще будут Flask или Django. Две классические грабли: путать def и async def в обработчиках, не понимая последствий для thread pool, и использовать одну и ту же Pydantic-модель для входа и выхода — так наружу утекают внутренние поля.
Как это работает
Основы FastAPI и проектирование API в Python — это FastAPI (async, типизированный, OpenAPI-first), Flask (sync, минималистичный, большая экосистема) и Django (batteries-included, ORM, admin). requests — де факто sync HTTP-клиент; httpx — его async-преемник. Pydantic — рантайм-валидация данных из type hints, на нём строятся request/response модели FastAPI. SQLAlchemy — универсальный ORM (1.x classic или 2.0 typed); Alembic — миграции схемы.
Когда применять
FastAPI — для новых async API с автогенерированными доками и Pydantic-валидацией; Flask — для крохотных сервисов или когда команда знает Flask наизусть; Django — когда нужны admin + ORM + auth из коробки (CMS-like, внутренние тулы). requests — для разовых скриптов, httpx — когда приложение async. SQLAlchemy — когда SQL уходит за тривиальный CRUD; для разовой аналитики raw SQL через sqlite3/psycopg часто понятнее.
Типичные ошибки
Ловушки Основы FastAPI и проектирование API: блокирующие вызовы внутри async-эндпойнтов FastAPI (используйте httpx, не requests); деплой Flask на dev-сервере в production (нужны gunicorn/uvicorn + reverse proxy); чрезмерная вера в Pydantic на performance-critical путях (валидация стоит — модели делайте худыми); lazy loading SQLAlchemy триггерит N+1 запросы (.options(joinedload(...)) или eager loading); коммит секретов в settings.py (используйте переменные окружения).
Связанные понятия
Полезные ресурсы
Проверить знания (1)
Загрузка вопросов…