Вы собрали интерфейс приложения. На экране есть карточки, кнопки и список данных. Пока всё хранится в JavaScript, прототип работает. Но как только данные должны приходить с сервера, появляется вопрос, откуда frontend будет их получать. Для этого нужен API. Он принимает HTTP-запрос и возвращает данные в согласованном формате. Django REST Framework позволяет создать такой интерфейс поверх Django без необходимости вручную собирать каждый JSON-ответ.
Начнём с простого API каталога. Он будет возвращать несколько товаров, а затем разберём, как этот подход развивается до настоящего приложения.
Что такое API на практике
Представьте страницу каталога. Пользователь открывает её, а браузер или сервер Next.js запрашивает список товаров. Запрос может выглядеть так.
GET /api/products/
Ответ содержит JSON.
[
{"id": 1, "name": "Кофе", "price": 490},
{"id": 2, "name": "Чай", "price": 290}
]
Frontend использует эти данные для отображения карточек. Ему не нужно знать, как Django получает товары, из какой таблицы читает их и какие внутренние функции вызывает. API задаёт границу между интерфейсом и серверной логикой.
Создаём проект Django
Установим Django и Django REST Framework.
pip install django djangorestframework
Создадим проект и приложение каталога.
django-admin startproject config .
python manage.py startapp catalog
Добавим приложения в INSTALLED_APPS файла config/settings.py.
INSTALLED_APPS = [
# Стандартные приложения Django
"rest_framework",
"catalog",
]
В настоящем settings.py сохраняются и стандартные приложения Django, созданные при старте проекта. Здесь показаны только две добавляемые строки. Теперь можно описать структуру ответа API.
Зачем нужен serializer
Serializer определяет, какие поля приложение возвращает клиенту и какие типы данных ожидаются. Для первого примера у товара будет идентификатор, название и цена.
Создадим catalog/serializers.py.
from rest_framework import serializers
class ProductSerializer(serializers.Serializer):
id = serializers.IntegerField()
name = serializers.CharField()
price = serializers.IntegerField()
Пока в проекте нет базы данных. Мы передадим сериализатору обычные Python-словари, чтобы увидеть принцип без дополнительных настроек.
Позже тот же подход можно применить к объектам модели Django. Тогда часто используют ModelSerializer, который связывает поля сериализатора с моделью.
Пишем первый endpoint
В catalog/views.py добавим обработчик запроса.
from rest_framework.decorators import api_view
from rest_framework.response import Response
from .serializers import ProductSerializer
@api_view(["GET"])
def products(request):
items = [
{"id": 1, "name": "Кофе", "price": 490},
{"id": 2, "name": "Чай", "price": 290},
]
serializer = ProductSerializer(items, many=True)
return Response(serializer.data)
Декоратор @api_view(["GET"]) разрешает запросы методом GET. Параметр many=True сообщает сериализатору, что мы передаём список объектов, а не один товар.
Response возвращает результат средствами Django REST Framework. Для обычного API-запроса клиент получает JSON.
Осталось подключить маршрут. В config/urls.py добавим путь к обработчику.
from django.contrib import admin
from django.urls import path
from catalog.views import products
urlpatterns = [
path("admin/", admin.site.urls),
path("api/products/", products),
]
Запустим сервер.
python manage.py migrate
python manage.py runserver
Теперь откройте http://127.0.0.1:8000/api/products/. Django REST Framework покажет ответ API в браузере. Данные можно получить и из любого HTTP-клиента.
Создали endpoint, который отвечает на GET-запрос и отдаёт список товаров. Базы данных пока нет, но граница между клиентом и сервером уже появилась.
Что делает serializer при получении данных
В примере serializer преобразует Python-объекты в структуру ответа. Но в API обычно нужны не только чтение, но и создание или изменение записей. Допустим, frontend отправляет название нового товара. Сервер не должен автоматически доверять каждому полученному полю. Его нужно проверить, прежде чем сохранять.
Django REST Framework позволяет передать входящие данные сериализатору и вызвать is_valid(). После успешной проверки доступно validated_data.
serializer = ProductSerializer(data=request.data)
if serializer.is_valid():
clean_data = serializer.validated_data
Здесь только проверяем структуру данных. Для создания товара в базе потребуется модель и логика сохранения.
Это следующий этап разработки. Начальный GET endpoint помогает увидеть движение данных, а затем к нему можно добавлять POST, редактирование и удаление.
Что меняется при подключении базы данных
Пока список товаров находится прямо внутри обработчика. Если перезапустить сервер, он останется тем же. Добавить товар через интерфейс невозможно. Для рабочего каталога понадобится модель Django, таблица базы данных и запросы к ней. Вместо массива из двух словарей обработчик будет получать записи из базы и передавать их сериализатору. Появятся и другие задачи. Например, нельзя разрешать любому посетителю менять цены, удалять чужие записи или получать личные данные пользователей.
Поэтому у API постепенно появляются авторизация и права доступа. При этом принцип остаётся прежним. Клиент отправляет запрос, Django обрабатывает его, а serializer помогает согласовать формат данных.
Как API соединяется с интерфейсом
Когда endpoint готов, к нему можно подключить React или Next.js. Но это уже отдельная задача. Там придётся учитывать адрес backend, обработку ошибок, загрузку данных и правила доступа между приложениями.
Связка frontend и backend разобрана в статье «Запрос, сериализатор, ответ и граница между Next.js и Django». Она продолжает тему после создания первого API.
В AI-Chat Django API используется как серверная часть приложения с интерфейсом на Next.js и подключением AI-сервисов.
Курс «AI на Django и Next II» последовательно соединяет серверные обработчики, авторизацию, API и работу frontend в одном проекте.
Первый endpoint даёт точку, от которой можно развивать приложение. Затем обычный список превращается в данные из базы, появляются пользовательские запросы и правила доступа. При этом клиент продолжает работать через понятный HTTP-интерфейс.