Django rest framework что это

Обновлено: 03.07.2024

Итак, вы учитесь использовать Django Web Framework и вы любите его. Но вам нужен привлекательный, простой в использовании API для вашего приложения? Посмотрите не дальше, чем Django Rest Framework (DRF). DRF является мощным, утонченный и удивительно простым в использовании. Он предлагает привлекательную, доступную в Интернете версию вашего API и возможность возврата сырого JSON. Django Rest Framework обеспечивает мощную сериализацию модели, отображение данных с использованием стандартных представлений, основанных на функциях, или получить гранулы с мощными представлениями на основе классов для более сложных функций. Все в полностью совместимой REST оболочке. Давайте начнем.

Укладка фундамента

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

Tuts + имеет два отличных видео о том, как установить virtualenv и virtualenvwrapper. Потратьте несколько минут, чтобы пройти через эти видеоролики, чтобы получить virtualenv и virtualenvwrapper, установленные на вашем компьютере. Если вы уже установили их, пропустите следующий раздел.

Настройка виртуальной среды

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

Неважно, где вы находитесь в файловой системе, когда эти команды запущены. Все файлы virtualenv хранятся в централизованном месте и активируются по требованию.

Установка приложения Django

Если в какой-то момент вы не получите ожидаемых результатов, попробуйте переключить ветвь локального репозитория в финал, чтобы увидеть результаты: git checkout final .

Fab? Что это?

«Fabric - это библиотека Python (2,5 или выше) и средство командной строки для оптимизации использования SSH для задач развертывания приложений или системного администрирования».

Хотя более полная дискуссия о Fabric выходит за рамки этой статьи, я внедрил некоторые основные команды fab, которые упрощают работу с этим приложением. Вы видели команду fab runserver . Существует также команда fab shell , которая вызывает интерактивную оболочку iPython в контексте приложения и команду fab syncdb , которая запускает команду syncdb Django для синхронизации изменений в моделях с базой данных.

Работа с сериализацией

Одной из мощных возможностей Django Rest Framework является встроенная сериализация модели, которую она предлагает. Имея всего несколько строк кода, вы можете создавать мощные представления ваших данных, которые могут быть доставлены в нескольких форматах. Как уже упоминалось ранее, наше приложение будет простым приложением хранения книг и авторов. Я уже создал для вас модели Author and Book , поэтому откройте /app/bookreview/models.py . Уже есть несколько авторов, хранящихся в локальной базе данных SQLite, поэтому давайте откроем интерактивную оболочку для нашего приложения и поработаем. Перейдите в окно терминала, убедитесь, что вы находитесь в ./app и введите следующую команду.

После загрузки оболочки введите следующие несколько строк, чтобы получить запись автора из базы данных, которая просто оказалась моей. Какое совпадение. :)

Аналогичным образом вы можете получить все записи автора из базы данных с помощью другой команды:

К сожалению, это не возвращает данные, которые может понять вызов AJAX. Итак, добавим сериализатор для авторов. Закройте оболочку, набрав quit и откройте bookreview / serializers.py . Введите или вставьте следующие несколько строк кода и сохраните файл.

Не внося никаких изменений, сериализатор дает нам довольно много мощи. Вернитесь в оболочку и давайте рассмотрим.

Давайте добавим еще несколько строк кода и посмотрим, что наш API покажет нам в браузере после того, как наши данные будут запущены через наш новый AuthorSerializer .

Проверка API-интерфейса, доступного в Интернете

Сначала откройте bookreview / urls.py и добавьте следующую строку сразу после маршрута index_view :

Затем откройте bookreview / views.py и добавьте эти строки в конец файла:

Затем добавьте импорт для AuthorSerializer в верхней части страницы:

Представление по умолчанию для Django Rest Framework - это APIView. Он позволяет вам определять свои методы get , put и delete . Это хороший способ получить базовую функциональность, но все же контролировать конечный результат. В нашем случае, однако, мы позволяем DRF делать тяжелый подъем для нас, расширяя ListAPIView. Нам просто нужно предоставить несколько бит информации, чтобы позволить DRF подключать куски. Мы даем ему модель автора , чтобы он знал, как разговаривать с базой данных, и AuthorSerializer , чтобы DRF знал, как вернуть информацию. Мы будем работать только с несколькими встроенными APIViews, но вы можете прочитать обо всех параметрах на веб-сайте Django Rest Framework.

Теперь, когда у нас есть представление API авторов, попробуйте нажать этот URL с помощью команды curl :

Довольно шумный, да?

Предоставьте несколько авторских книг!

Хотя этот вид API довольно красивый, он один-к-одному с базой данных. Давайте перейдем к нашему представлению API, составив более сложный набор данных для авторов, включив список всех своих книг. Откройте bookreview / serializers.py и добавьте следующую строку кода перед определением класса AuthorSerializer .

Прежде чем мы сможем добавить книги в AuthorSerializer , мы должны сериализовать книги. Это должно быть полностью знакомо вам. Поскольку он почти идентичен AuthorSerializer , мы не будем обсуждать его.

Затем добавьте следующую строку сразу после docstring класса AuthorSerializer :

Затем добавьте книги в свойство полей внутреннего класса Meta AuthorSerializer :

Перезагрузите /authors/ в конечном результате, и теперь вы должны увидеть массив книг для каждого автора. Неплохо бы еще несколько строк кода, да?.

Хороший парень DRF!

Использование SerializerMethodField для создания пользовательских свойств

Сериализатор умный . когда мы укажем, какую модель он должен сериализовать внутри внутреннего метакласса, он знает все об этой модели . свойствах, длине, значениях по умолчанию и т. д. Обратите внимание, что мы не определяем какие-либо свойства, найденные в модели непосредственно в сериализаторе, мы укажем только, какие поля должны быть возвращены API в свойстве fields .

Поскольку DRF уже знает о свойствах модели, это не требует от нас повторения. Если бы мы хотели, мы могли бы быть явными в BookSerializer и добавлять следующие строки . и DRF был бы так же счастлив.

Метод serializers.field позволяет указать на существующее свойство модели, исходное поле и позволяет явно называть его чем-то другим при возврате его конечному пользователю. Но как насчет serializers.SerializerMethodField ? Это позволяет вам по существу создать настраиваемое свойство, которое напрямую не привязано к модели, содержимое которой является результатом вызова метода. В нашем случае мы вернем URL-адрес, который содержит список мест, куда вы могли бы пойти, чтобы купить книгу. Давайте добавим этот пользовательский метод.

Сразу после строки документации BookSerializer добавьте следующую строку:

Затем после определения класса Meta BookSerializer добавьте следующие строки:

Затем, наконец, нам нужно добавить наше новое свойство в список полей. Измените это:

Перезагрузите /authors/ в конечном результате, и теперь вы должны увидеть URL-адрес, возвращающийся вместе с другой информацией о книге.

Добавление конечной точки автора

У нас уже есть список авторов, но было бы хорошо, если бы у каждого автора была своя страница . точно так же, как MySpace? Позволяет добавить конечную точку API для просмотра одного автора. Откройте urls.py и добавьте следующую строку после маршрута author-list :

Затем откройте view.py и добавьте следующие строки после класса AuthorView :

Нажмите одно из имен авторов на индексной странице, и вы увидите, что страница авторского экземпляра загружается.

Рефакторинг для победы!

Теперь самое подходящее время для быстрого рефакторинга. Поскольку Django предлагает вариант назначения ваших маршрутов, мы можем ссылаться на маршрут по этому имени. Это не позволяет нам создавать URL-адрес вручную. Откройте templates/index.html и замените следующий фрагмент:

Сохранение данных: пусть DRF работает для вас!

До сих пор наше приложение было только для чтения. Пора начать сохранять некоторые данные. Откройте templates/index.html и добавьте следующие строки под заголовком авторов:

Введите имя, ваше, если хотите, и нажмите submit . и скоро, вы получите . ошибку?

DRF не совсем такой магический . или не так ли?

Откройте views.py , измените класс, который AuthorView расширяет с generics.ListAPIView на generics.ListCreateAPIView . Затем повторите попытку. Бум! Вы автор! И ваш учитель гимнастики четвертого класса сказал, что вы ни на что не годитесь. Но что он знал, он работал каждый день вокруг потных носков. Вернитесь на главную страницу автора, чтобы увидеть свое имя в огнях.

Что сейчас произошло? По умолчанию API View, который мы использовали, разрешал только запросы GET конечной точке авторов. Изменив его на ListCreateAPIView, мы сказали DRF, что хотим также разрешить POST запросы. Он делает все остальное для нас. Мы могли бы также легко определить наш собственный метод post в AuthorView и написать немного лишнего материала. Это может выглядеть так:

Заканчиваем

Вы уже много узнали о платформе Django Rest Framework: как реализовать API-интерфейс для просмотра веб-страниц, который может вернуть JSON для вас, как настроить сериализаторы для составления и преобразования ваших данных, а также как использовать представления на основе классов для абстрагирования кода шаблона.

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

Я написал эту статью, чтобы рассказать в ней теорию, которая будет необходима для изучения Django REST Framework. Информация, изложенная в этой статье, не является исчерпывающей в данной теме и показывает историю развития веб-приложений лишь отчасти. Я просто постараюсь объяснить, почему этот фреймворк — часть естественной эволюции веб-технологий, и как при помощи него мы можем по-новому решать старые задачи веб-разработки.

Чтобы ответить на вопрос, что же такое Django REST Framework, нужно разобраться со всей необходимой терминологией.

Framework

Создавая приложение или любой другой программный продукт, мы хотим делать это быстро и качественно. Проще этого добиться, используя опыт и наработки других разработчиков, ведь многие задачи, которые мы встречаем в процессе работы, уже были кем-то решены. По сути, использование фреймворка позволяет сосредоточится на задачах бизнеса и не задумываться над техническими деталями там, где это возможно. Нужно отрисовать кнопку на сайте? Сделать авторизацию или сброс пароля? Сохранить данные пользователя из формы на сайте в базу данных? Для этого всё уже готово — бери и пользуйся!

Также важно понимать отличия Framework от библиотеки. Это похожие вещи. В обоих случаях в Python вы должны установить нужный пакет, импортировать и пользоваться им. Разница в том, что библиотеку в проекте вы используете там, где нужно, и так, как вы хотите, а фреймворк сам определяет способ разработки приложения, то есть не только предоставляет удобные инструменты разработки в виде вспомогательных функций и классов, но и непосредственно формирует архитектуру проекта, создает структуру кода, проще говоря, определяет путь, по которому вы будете создавать свое приложение.

Django

На сегодняшний день наиболее функциональным фреймворком для создания веб-приложений на языке Python является фреймворк Django. Django можно назвать MVC-фреймворком, так он реализует взаимодействие пользователя и системы:

Model (хранит данные пользователя)

View (отображает данные пользователя)

Controller (принимает изменения данных от пользователя).

Внутри Django эта терминология звучит немного иначе, но суть остается той же.

Разработка Django началась в 2003 году программистами Adrian Holovaty и Simon Willison, а публичный релиз состоялся в 2005 году. Функционал фреймворка хорошо отвечал требованиям в веб-разработке того времени. Он активно развивается и до сих пор. Хотя этот фреймворк и считается довольно крупным и многофункциональным, сам по себе он не мог удовлетворить все запросы веб-разработчиков. За время его существования сторонними разработчиками было создано огромное множество библиотек и фреймворков в качестве дополнений к Django, которые упрощают реализацию тех или иных задач: аутентификация через социальные сети, кеширование данных, хранение файлов в облаке и многое другое. Некоторые из дополнений со временем сами стали частью проекта Django, как это произошло с библиотекой South, управляющей миграциями базы данных. Но большинство дополнений так и остались независимыми пакетами. Одним из них и является Django REST Framework, при помощи которого мы можем создавать Web API на основе Django.

Web API

Сегодня сеть интернет построена по принципу Клиент-Серверного взаимодействия. Клиент посылает запрос — Сервер ему отвечает. В случае, когда между собой общаются два Сервера, мы условно называем Клиентом того, который отправил запрос и ожидает ответ, а Сервером будет тот, кто принимает запрос и отвечает не него. Взаимодействие браузеров и веб-сайтов (первые выступают в роли Клиента, а вторые в роли Сервера) традиционно делалось при помощи технологии html-рендеринга, именно так изначально это делал Django. Чтобы получить данные с веб-сайта, браузер отправляет запрос GET к Серверу. Сервер формирует ответ в виде html-страницы и передает ее браузеру. Так Сервер передает данные браузеру, но как браузер может передать данные Серверу? В этой самой html-странице Сервер заложил все необходимые веб-формы, заполнив которые, пользователь мог бы передать свои данные обратно на сервер. Когда вы ввели свои данные в форму на сайте, бразуер отправляет Серверу запрос POST, в котором содержатся ваши данные, а Сервер обрабатывает их и записывает в базу данных.

Все это отлично работало, но уже в середине нулевых такой подход перестал удовлетворять возрастающим требования в веб-разработке. Появлялись мобильные приложения, различные гаджеты с доступом в интернет, и для них уже не подходил стандартный способ html-рендеринга на сервере, ведь теперь каждому клиенту нужно было отрисовать данные по-своему. Постоянно увеличивалось взаимодействие серверов друг с другом, и html-формат уже не подходил. Для всех этих задач есть другой способ обмена данными — Web API. Смысл этого способа в том, что Сервер передает Клиенту не html-страницу, а непосредственно данные, никак не влияя на то, как эти данные будут в итоге представлены. Наиболее популярными форматами для передачи данных становятся XML и JSON. Таким образом Сервер полностью избавляется от задачи отрисовки данных. Какое-то время длился переходный период, когда разработчикам веб-приложений на Сервере приходилось поддерживать оба способа одновременно: html рендерился на Сервере для браузеров, а Web API использовался для мобильных приложений и интеграции с другими серверами. Понятно, что разработчикам приложений на Сервере приходилось делать двойную работу. Но в начале десятых ситуация стала меняться в пользу Web API. Этому способствовало молниеносное развитие инструментов на языке JavaScript, а также появление различных веб-фреймворков, одним из которых и является предмет данной статьи.

Браузерные приложения быстро научились отрисовывать веб-страницы самостоятельно, получая чистые данные с Сервера. Веб-приложения на сервере научились создавать API быстро и легко. Так сформировалась четкое разделение на Backend и Frontend разработку: тех, кто поддерживает приложение на Сервере, и тех, кто делает браузерные (клиентские) приложения. А Web API стал универсальным способом общения для Сервера и всех его клиентов (браузеров, мобильных приложений, других Серверов). Конечно, это не могло не привести к развитию стандартов в общении между системами. И Клиенту, и Серверу необходимо знать каким образом общаться с друг с другом, как передавать данные, как сообщать об ошибках. Разработчики всегда могли договориться о том, как взаимодействовать их приложениям, но наличие некоего стандарта в веб-разработке позволило бы эту задачу облегчить. И вот в начале десятых таким стандартом стала концепция REST.

В 2000 году Рой Филдинг написал докторскую диссертацию, где изложил концепцию REST. Там были рекомендации о том, как спроектировать Сервер, чтобы ему было удобно общаться с Клиентами. Выделю два главных принципа создания приложений в стиле REST:

Сервер не должен ничего знать о текущем состоянии Клиента. В запросе от Клиента должна быть вся необходимая информация для обработки этого запроса Сервером.
Каждый ресурс на Сервере должен иметь определенный Id, а также уникальный URL, по которому осуществляется доступ к этому ресурсу.

На данный момент мы можем найти фреймворк для создания приложений в стиле REST практически для каждого языка программирования, используемого в веб-разработке. Логика построения Web API на Сервере в этих фреймворках реализована одинаково.

У нас есть объект Кошка, и мы хотим создать запись о кошке на Сервере. Для этого мы отправляем запрос на сервер:

С данными в теле запроса

Плюс к этому запросу (и все другим) будет добавлен ключ аутентификации.

Ключ будет нужен, чтобы Сервер понял, что запрос происходит от авторизованного Клиента. Как мы помним из правила REST, каждый запрос от Клиента должен содержать всю необходимую информацию для обработки этого запроса Сервером. Здесь это правило работает: Сервер ничего не знает о Клиенте до запроса, но сам запрос содержит ключ авторизации, по которому Сервер определяет, что это за Клиент.

Сервер взял все поля, переданные клиентом, и добавил к ним поле Id. Здесь работает правило REST, согласно которому каждый ресурс должен иметь уникальный идентификатор и быть доступным по определенному URL. Сервер создал ресурс и вернул нам его Id.

Теперь мы можем получить данную запись по URL

Что, если Клиент хочет изменить созданные им данные на сервере?

С телом запроса:

Метод PUT используется для изменения данных. Номер 21 в URL говорит о том, какой именно объект нужно изменить. Теперь наша кошка имеет цвет “Black”.

С телом запроса:

Тут также мы указываем в Id объекта в URL, но передавать никаких данных в теле запроса для удаления объекта уже не требуется.

Django REST Framework

Наконец, мы добрались до главной темы этой статьи. Мы вкратце разобрали каждый компонент этого словосочетания и теперь сможем понять, зачем использовать этот фреймворк, и какие задачи он решает.

Тут я бы хотел процитировать слова Тома Кристи, создателя Django REST Framework.

“Неудивительно, что Django REST framework — это API фреймворк для Django. И он пытается заполнить все пробелы в том, как исторически был спроектирован веб-фреймворк Django”.

И действительно, пусть Django был спроектирован давно, он до сих отлично решает свои задачи. Однако с появлением новых требований в веб-разработке, отсутствие компонентов для создания Web API воспринимается как пробел.

Django REST framework способен этот пробел заполнить.

А мы уже заполнили все пробелы в теории и терминологии и готовы перейти к практике!

Мы рассказываем, как стать более лучшим разработчиком, как поддерживать и эффективно применять свои навыки. Информация о вакансиях и акциях эксклюзивно для более чем 8000 подписчиков. Присоединяйся!

Меня зовут Стас Гаранжа, я выпускник курса «Python-разработчик» в Яндекс.Практикуме. Я хочу помочь начинающим разработчикам, которые приступили к изучению Django Rest Framework (DRF) и хотят разобраться, как устроен этот фреймворк.

Я готовлю цикл статей, в которых расскажу о разных сторонах работы DRF. У меня пока нет значимого практического опыта для описания всех изюминок при работе с этим фреймворком, поэтому в основе статьи — исследование, обобщение и по возможности непротиворечивое изложение того, что у DRF под капотом.

В этой статье разберёмся, как сделать REST API на базе Django Rest Framework, чтобы получить по GET-запросу набор записей из базы данных (БД). Иными словами, рассмотрим, как DRF работает на чтение (о том, как с помощью него создавать, изменять и удалять записи в БД, поговорим в отдельной статье).

Общую схему решения этой задачи мы рассмотрим в первой части статьи. Вторая будет посвящена детальному разбору процесса сериализации данных.

Несколько вводных замечаний:

Учебный проект, на основе которого даны все примеры в статье, можно найти в репозитории на Гитхабе.
Стиль и объём изложения рассчитаны на тех, кто не знаком с DRF и только начинает свой путь в разработке.
Предполагается, что читатель в общих чертах уже знаком с Django и знает основы ООП на Python.

Надеюсь, статья станет хорошим подспорьем изучения DRF и работы с его документацией, прояснит процесс сериализации данных и даст уверенность, что любая магия исчезает, стоит только покопаться под капотом конкретной библиотеки.

API для сайта на Django: общая схема

Задача

id	country	capital_city	capital_population	author (FK)
1	Norway	Oslo	693500	1
2	Sweden	Stockholm	961600	1
3	Finland	Helsinki	655300	1
4	Iceland	Reykjavik	128800	1

Поле author через внешний ключ (foreign key) связано с моделью User, в которой есть вся информация о пользователе с конкретным id.

Мы хотим получить информацию из базы данных, не открывая сайт в браузере, а сделав запрос из другого Python-приложения.

В каком виде нужно получить информацию:

Набор информации должен быть списком из Python-словарей: ключ — название поля записи в таблице Capital, значение — содержимое конкретного поля.
Названия стран нас не интересуют — нам нужны названия столиц, численность населения, а также имя сотрудника, который внёс запись в базу. Имя получаем через id автора, указанный в поле author .
Для передачи по сети полученные из БД данные должны быть конвертированы в json-формат.

Таким образом, каждую запись, которая при извлечении из базы данных является Python-объектом, принимающее приложение после декодирования json-строки должно получать в виде словаря:

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

Решаем задачу с помощью Django Rest Framework

Задача решается в два шага:

Сложный объект (набор записей из Django-модели) нужно превратить в более простую структуру, в нашем случае в список словарей. Понадобится сериалайзер.
Сериализованные данные для дальнейшей передачи по сети нужно перевести (отрендерить) в json-формат — универсальный текстовый формат передачи данных, не зависящий от языка реализации. Понадобится рендер.

Небольшое отступление о json. Базовые структуры данных на python кодируются в json и декодируются обратно следующим образом:

Python	JSON	Пример Python	Пример JSON
dict	object
list, tuple	array	['элемент1', 'элемент2'], ('элемент1', 'элемент2')	["элемент1", "элемент2"]
str	string	'элемент1'	"элемент1"
int, float, int- & float-derived Enums	number	5, 4.2	5, 4.2
True	true	True	true
False	false	False	false
None	null	None	null

Создаём сериалайзер

Каждая запись в таблице Capital — объект. И как у любого объекта, у записи есть свои атрибуты. Изучим их на примере первой записи о столице Норвегии, воспользовавшись атрибутом __dict__ . Нам доступен словарь, который хранит информацию о динамических (writable) атрибутах объекта:

Каждое поле модели Capital — атрибут объекта конкретной записи. При этом поле author , которое через внешний ключ связано с моделью User и содержит id объектов из неё, в атрибуте записи и в БД получает приставку _id .

Сериалайзер поможет достать данные из нужных атрибутов (полей) записи и сформировать упорядоченный python-словарь — объект класса OrderedDict . Отмечу, что в Python с версии 3.7 и «обычные» словари стали сохранять порядок вставки пар «ключ — значение».

Для сериалайзера нужно описать поля: каждое поле будет отвечать за извлечение и представление данных из корреспондирующего поля табличной записи.

Важный момент: здесь мы рассматриваем сериалайзер на основе базового класса Serializer , чтобы лучше понять принципы его работы. На более высоком уровне абстракции есть класс ModelSerializer , который позволяет частично уйти от ручного создания полей. В этой статье он не рассматривается.

Нас интересуют данные, которые есть в трёх полях каждой табличной записи:

поле capital_city ,
поле capital_population ,
поле author .

Значит, в сериалайзере должно быть тоже три атрибута-поля.

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

Вот примеры трёх вариантов названий полей сериалайзера:

Но как сериалайзер понимает, в каком порядке стыковать собственные поля с полями табличной записи? Например, если поле сериалайзера условно называется a , то как он определяет, что его нужно состыковать с полем записи capital_city ?

Теперь нужно выбрать тип поля сериалайзера. Его нужно соотнести с тем, какие данные извлекаются из корреспондирующего поля табличной записи. Дело в том, что у каждого поля сериалайзера есть собственный метод to_representation . Как следует из названия, задача метода — представить извлечённые из записи данные в определённом виде.

Например, есть поле serializers.IntegerField . Посмотрим на его метод to_representation :

Очевидно, этот тип поля сериалайзера нельзя выбирать для данных из табличной записи о названии столицы: int('Осло') вызовет ValueError. А вот для данных о численности населения — самое то.

Выберем следующие типы полей сериалайзера:

О соотношении полей сериалайзера и полей Django-моделей можно прочитать в документации DRF.

Код сериалайзера разместим в том же приложении, где находится Django-модель, под именем serializers.py:

В поле CharField указан необязательный параметр max_length , благодаря которому задаётся максимально допустимая длина передаваемого значения. О других параметрах поля написано в документации.

Пропущенный через сериалайзер набор табличных записей доступен в атрибуте сериалайзера data . Посмотрим на содержимое этого атрибута, создав тестовый вариант сериалайзера.

Сериалайзер в действии

Обратимся к файлу serializer_example_1.py . Он имитирует работу сериалайзера без необходимости запускать сервер и делать запрос к сайту. После клонирования учебного проекта и установки зависимостей (шаги 1—6 из ридми) достаточно запустить файл как обычный Python-скрипт и посмотреть в консоли результат его работы.

В serializer_example_1.py созданы классы с данными об авторах и о столицах для записей в таблицах:

Созданы объекты соответствующих записей:

Объединены записи в список по подобию кверисета из Django-модели:

Объявлен класс сериалайзера: код идентичен тому, который был приведён выше для class CapitalSerializer(serializers.Serializer) . Затем создали его экземпляр:

При создании мы передали сериалайзеру набор записей, которые нужно преобразовать. Они передаются в аргументе instance .

Кроме того, мы указали аргумент many со значением True . Дело в том, что логика работы сериалайзера с одной записью и с набором записей разная. Указывая many=True , мы включаем логику обработки набора записей. В чём она заключается, расскажу во второй части статьи при детальном разборе работы сериалайзера.

Выведем в консоль содержимое атрибута data сериалайзера:

Каждая запись из набора превратилась в упорядоченный словарь класса OrderedDict . Он находится в Python-модуле collections . Поэтому, если взглянуть на строки импорта в исходном коде restframework.serializers , можно увидеть:

В каждом OrderedDict содержится информация только из тех полей табличных записей, которые были состыкованы с полями сериалайзера. Данных о содержимом поля country нет — сериалайзер не настроен доставать эту информацию, потому что мы не создавали корреспондирующего поля в сериалайзере.

Отображаем (рендерим) информацию в формате json

Нам понадобится рендер — объект класса JSONRenderer . В файле serializer_example_2.py мы дополнили импорт — помимо модуля сериалайзеров из restframework мы импортировали модуль рендеров.

Далее необходимо создать экземпляр рендера нужного типа и вызвать у него метод render :

В результате мы увидим байтовую строку с массивом json-объектов:

Эта байтовая строка и будет передаваться по сети в атрибуте ответа content , а принимающее приложение будет её декодировать в список из Python-словарей и вытаскивать нужную информацию из каждого.

Что нужно ещё

Итак, мы испытали сериалайзер и посмотрели, как пропущенный через него набор табличных записей был преобразован в json-формат.

Чтобы сайт начал отдавать сериализованные данные, остаётся описать контроллер (view) и указать url-маршрут — эндпоинт, при обращении к которому сайт будет отдавать данные о столичных городах.

Контроллер

Во views.py создадим класс контроллера. Нам понадобятся следующие инструменты DRF:

Внутри контроллера описываем один метод — get. Почему он называется именно так?

Пример: если поступил GET-запрос, то будет задействован метод get контроллера.

В методе get опишем ту же логику, что и в файле с пробным запуском сериалайзера:

Подготовить набор записей.
Создать экземпляр сериалайзера, который может обрабатывать не отдельную запись, а их набор ( many=True ).
Отрендерить в json-формат данные, полученные от сериалайзера.

В отличие от файла serializer_example_2.py , где мы явно прописывали json-рендер и вызывали у него метод render , в коде контроллера ничего такого нет. Но рендер всё равно отработает: его работа описана под капотом внутри класса-родителя APIView .

После того как отработал метод get, работа контроллера выглядит так:

Объект ответа, который вернул метод get ( return Response( ), передаётся в метод finalize_response родительского класса APIView .
В методе finalize_response объекту ответа добавляются атрибуты:
- accepted_renderer — им как раз выступает объект JSONRenderer,
- accepted_media_type — 'application/json',
- context .

Благодаря этим атрибутам формируется rendered_content : у экземпляра JSONRenderer срабатывает метод render , который возвращает байтовую строку с данными в json-формат. Она помещается в атрибут ответа content .

Маршрут (эндпоинт)

Здесь та же схема действий, как в классическом Django. Подключаем маршруты приложения capitals:

Прописываем сам маршрут в приложении capitals и связываем маршрут с контроллером:

API в действии

Чтобы посмотреть, как работает API, можно:

Осталось выполнить шаги 2 и 3.

Если всё отработало штатно, в корневой директории проекта появится файл capitals.txt со следующим содержимым:

Несмотря на то, что пример наивный, он показывает главное: как мы научили
веб-приложение отдавать информацию из базы данных в ответ на запрос, который поступает не от человека через браузер, а от другого приложения. И далее — как это приложение использует полученную информацию.

Browsable API — удобный инструмент для тестирования API на DRF

Django Rest Framework позволяет посмотреть в браузере, какую информацию будет отдавать API при обращении к конкретному маршруту (эндпоинту). Достаточно ввести маршрут в адресную строку, и откроется страница с данными о запросе и результате его выполнения. За такое отображение отвечает BrowsableAPIRenderer.

Итак, мы рассмотрели, как сделать API на базе DRF, чтобы получить по GET-запросу набор записей из Django-модели. Во второй части подробно разберём работу сериалайзера на чтение.
Если у вас появились вопросы по решению задачи, пишите в комментариях.

Термин REST API расшифровывается как Representational State Transfer Application Programming Interface. Следовательно, RESTful API — это программный интерфейс приложения, соответствующий ограничениям архитектурного стиля REST.

REST — не протокол и не стандарт. Это, как уже было сказано, архитектурное ограничение. Чтобы API считался RESTful, он должен соответствовать следующим критериям.

Благодаря вышеперечисленным архитектурным правилам REST API масштабируемый, переносимый и гибкий.

2. Что такое Django REST Framework?

Django — масштабируемый полнофункциональный веб-фреймворк, написанный на Python. Django берет на себя все хлопоты, зачастую связанные с веб-разработкой, такие как безопасность и доступ к базам данных.

Существует множество библиотек для Django, расширяющих его функционал. Одна из них, о которой мы поговорим сегодня, — это Django REST Framework или DRF, которая позволяет сериализовать данные из Django ORM через REST API.

Сериализация — это преобразование таблиц из базы данных в формат JSON.

Руководство написано для новичков, прошлый опыт работы с фреймворком Django не предполагается, так как вы многому научитесь прямо сейчас. Кроме того, в статье не будет обширного описания технических нюансов каждой операции. Рассматривайте руководство в качестве упражнения.

Давайте создадим сайт бронирования отелей! Исходный код и справка доступны на GitHub.

3. Установка Django

Прежде чем приступить непосредственно к работе с REST API, сделаем краткий экскурс в Django.

3.1. Создание виртуальной среды

3.2. Установка зависимостей

3.3. Начало проекта

3.4. Изменение директории

3.5. Запуск сервера

3.6. Создание приложения

Приложения в Django — это независимые многократно используемые компоненты. Создадим приложение hotel_app .

3.7. Список приложений в проекте

Чтобы подключить к проекту hotel_reservation приложения hotel_app и rest_framework , необходимо отредактировать файл results/settings.py , указав эти приложения в списке INSTALLED_APPS :

3.8. Миграции

Теперь нужно выполнить Django-миграции — это способ Django распространять в схему базы данных все изменения, вносимые в модели, такие как добавление поля, удаление модели. Выполняйте эту команду каждый раз, когда модель или база данных сколько-нибудь меняются:

3.9. Административная панель

Django поставляется со встроенной панелью администратора, что позволяет создать суперпользователя с помощью одной команды. Заполните форму — появится учетная запись администратора:

Снова выполните миграции, авторизуйтесь.

3.10. Создание модели

Django ORM абстрагирует базу данных, позволяя легко запрашивать данные и манипулировать ими через объектно-ориентированное отображение, называемое моделью. Django ORM заставляет писать код согласно паттерну MVC (Model View Controller), который станет интуитивно понятным для вас после прохождения кривой обучения.

hotel_app/models.py :

Мы создали модель, хранящую имя студента и его оценки. Метод __str__ определяет имя объекта, отображаемое в браузере. Если пропустить определение данного метода, то вы увидите в панели администратора объект под названием <ClassName> .

3.11. Не забывайте о миграциях!

Теперь, когда изменения уже внесены в модель, настало время выполнить миграции.

3.12. Добавление приложения в админ-панель

Во встроенное приложение административной панели можно добавить созданную ранее пользовательскую модель.

hotel_app/admin.py :

Теперь мы завершили ту общую часть разработки веб-приложения, которая относится к фреймворку Django. Настало время приступить к проектированию REST API.

4. Написание Django REST API

Структура директорий проекта:

Добавим в проект файлы urls.py и serializers.py . Вот новый список файлов.

4.1. Сериализатор

Сериализация — процесс перевода структуры данных в последовательность байтов. Она используется для передачи объектов по сети и для сохранения их в файлы (Википедия).

hotel_app/serializers.py :

Сериализаторы определяют, как именно и какие данные отобразит представление API. При запросе по REST API к экземпляру модели Hotel мы получим список следующих полей, взятых из самой модели при помощи сериализатора:

4.2. Представления

Файл представления определяет то, как сериализованные объекты отображаются пользователю.

4.3. URL: ссылки на ресурсы

hotel_app/urls.py :

hotel_reservation/urls.py :

Перейдя по данной ссылке, вы получите доступ ко всем ранее определенным “разделам” REST API проекта:

5. Выводы

Читайте также: