← Все статьи

Создание REST API на FastAPI: пошаговое руководство для Python (2026-03-21 14:00:57) | Блог ГК ЖУР

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

Перед началом работы убедитесь, что у вас установлен Python версии 3.7 или выше. Первым делом создадим изолированное окружение для проекта, чтобы избежать конфликтов зависимостей. Это можно сделать с помощью встроенного модуля venv.

Откройте терминал в папке вашего будущего проекта и выполните команду для создания виртуального окружения. После активации окружения установим необходимые пакеты. Нам понадобится сам FastAPI, а также сервер для запуска приложения вроде Uvicorn или Hypercorn.

  • pip install fastapi
  • pip install uvicorn[standard]

Теперь создайте новый файл с названием main.py. Это будет точка входа в наше приложение. Начнем с импорта FastAPI и создания экземпляра приложения.

Внутри файла main.py напишите несколько строк кода. Импортируйте класс FastAPI и создайте его экземпляр с именем app. Это основной объект, который будет обрабатывать все запросы.

Давайте сразу создадим наш первый маршрут или endpoint. В FastAPI это делается с помощью декораторов. Например, чтобы создать endpoint для GET-запроса по корневому пути /, используйте декоратор app.get("/"). Под ним определите функцию, которая будет возвращать данные пользователю.

Этот простейший endpoint уже можно запустить. Вернитесь в терминал и выполните команду uvicorn main:app --reload. Флаг reload позволяет автоматически перезагружать сервер при изменениях кода, что очень удобно во время разработки.

Перейдите в браузере по адресу http://127.0.0.1:8000/. Вы должны увидеть ответ вашей функции, например {"message": "Hello World"}. Но настоящая магия FastAPI ждет вас по адресу http://127.0.0.1:8000/docs.

FastAPI автоматически генерирует интерактивную документацию Swagger UI на основе вашего кода и аннотаций типов Python (Pydantic). Это одна из его killer features — вам не нужно писать документацию отдельно; она создается сама и всегда актуальна.

Теперь давайте углубимся и создадим что-то более полезное — например, простое API для управления списком задач (To-Do list). Для этого нам понадобятся модели данных Pydantic.

Создайте новый файл schemas.py или определите классы прямо в main.py для простоты. Модель Pydantic описывает структуру данных: что мы ожидаем получить от клиента (при создании задачи) и что мы ему возвращаем.

Определите две схемы: TaskCreate (с полями title и description) и Task (которая наследует от TaskCreate и добавляет поля id и is_completed). Аннотации типов здесь критически важны — они используются для валидации данных, сериализации и генерации документации.

Теперь реализуем CRUD операции (Create, Read, Update, Delete). Для хранения данных временно используем обычный список в памяти Python вместо базы данных — это позволит сосредоточиться на логике API.

  • GET /tasks — для получения списка всех задач.
  • GET /tasks/{task_id} — для получения одной задачи по её ID.
  • POST /tasks — для создания новой задачи.
  • PUT /tasks/{task_id} — для обновления существующей задачи.
  • DELETE /tasks/{task_id} — для удаления задачи.

В каждом эндпоинте функция будет принимать соответствующие параметры: path-параметры (как task_id), query-параметры или тело запроса (объект Pydantic модели). FastAPI автоматически парсит запросы, валидирует данные согласно аннотациям типов и передает их в вашу функцию.

Например, функция для создания задачи будет объявлена как async def create_task(task: TaskCreate). FastAPI знает, что параметр task должен быть взят из тела POST-запроса, проверит его на соответствие модели TaskCreate и только затем передаст управление вашей функции.

Не забудьте про обработку ошибок. Что если пользователь запросит задачу с несуществующим ID? В таких случаях нужно возвращать соответствующий HTTP - статус код, например 404 Not Found.

FastAPI предоставляет удобный механизм через HTTPException из модуля fastapi. Просто импортируйте его и вызовите внутри функции при обнаружении ошибки условия: raise HTTPException(status_code=404, detail="Task not found").

После того как основная логика готова, стоит подумать о подключении реальной базы данных. Для демонстрации часто используют SQLite как самый простой вариант. Однако FastAPI работает с любыми базами: PostgreSQL, MySQL, MongoDB.

Рекомендуемый подход — использование асинхронных драйверов базы данных вместе с ORM, таким как SQLAlchemy в асинхронном режиме ( asyncpg ) или Tortoise - ORM. Вам нужно будет определить модели базы данных, настроить подключение ( dependency injection ) и адаптировать функции endpoints для работы с БД вместо списка.

Один из мощных концептов FastAPI — Dependency Injection ( внедрение зависимостей ). Он позволяет легко управлять подключениями к БД, аутентификацией, проверкой прав доступа. Вы можете создать функцию - зависимость get_db(), которая будет открывать сессию с базой данных перед обработкой запроса и закрывать её после.

Когда ваш API готов к работе в production - среде, необходимо позаботиться о деплое. Uvicorn может работать самостоятельно, но лучше использовать его за reverse proxy - сервером типа Nginx. Также рассмотрите использование менеджера процессов Gunicorn совместно с Uvicorn workers для лучшей стабильности.

FastAPI делает процесс разработки API невероятно быстрым за счет автоматизации рутинных задач: валидации, сериализации, документирования. При этом он не скрывает сложность там, где она нужна: вы всегда можете тонко настроить поведение под свои требования.

Таким образом, FastAPI представляет собой идеальный баланс между простотой использования для новичков и мощью для опытных разработчиков. Потратив немного времени на изучение его основ, вы сможете создавать надежные, производительные и хорошо документированные веб - сервисы.

💬 Комментарии (12)
👤
natalya.volkova99
21.03.2026 17:01
Отличное пошаговое руководство! Как раз искал современную альтернативу Flask для нового проекта. Автоматическая документация Swagger - просто бомба.
👤
dmitry.popov77
21.03.2026 17:01
Спасибо за статью! Всё четко и по делу. FastAPI действительно впечатляет своей скоростью и простотой, особенно после Django REST Framework.
👤
feedback-2024
21.03.2026 17:01
Интересно, насколько сложно будет интегрировать такую API-шку с уже существующим монолитом на Django? Есть ли у кого опыт?
👤
security.agent1
21.03.2026 17:01
Статья хорошая, но чувствуется, что написана для новичков. Хотелось бы углубиться в продвинутые темы: dependency injection, фоновые задачи, кастомные middleware.
👤
patrick.king12
21.03.2026 17:01
Автор, а планируете ли выпустить вторую часть с более сложным примером? Например, с JWT-аутентификацией и ролевой моделью доступа.
👤
andrey.medvedev
21.03.2026 17:01
Попробовал по инструкции - всё заработало с первого раза! Pydantic для валидации - это гениально и очень удобно. Рекомендую всем.
👤
mikhail.petrov
21.03.2026 17:01
Всё хорошо, но не раскрыта тема обработки ошибок. Как правильно возвращать 404 или 500 с понятным описанием для клиента?
👤
pavel.nikolaev55
21.03.2026 17:01
FastAPI - отличный выбор для микросервисов. Использую его в продакшене уже год, производительность на уровне Go-фреймворков. Статья попадает в точку.
👤
newsletter.list2024
21.03.2026 17:01
А есть ли смысл переходить на FastAPI с aiohttp? Вроде оба асинхронные. Какие ключевые преимущества у FastAPI в этом сравнении?
👤
kevin.white123
21.03.2026 17:01
Спасибо за труд! Материал изложен структурированно. Отдельный респект за указание даты - видно, что информация актуальная для 2026 года.
👤
maxim.fedorov77
21.03.2026 17:01
Не совсем согласен, что фреймворк 'простой в освоении'. Для джунов синтаксис async/await и типизация Pydantic могут быть барьером. Но статья помогает.
👤
robert.taylor2024
21.03.2026 17:01
Подскажите, а как в таком API лучше организовать структуру проекта для чего-то большего, чем один файл? Где хранить модели, роутеры, утилиты?