Что такое django rest framework

Обновлено: 02.07.2024

В этом руководстве мы создадим REST API на Python с Django, используя Django REST Framework для создания приложения корзины покупок.

Примечание. Полный код этого приложения можно найти на GitHub.

Что такое REST API?

API (интерфейс прикладного программирования), как следует из названия, представляет собой интерфейс, определяющий взаимодействие между различными программными компонентами. Веб-API определяют, какие запросы можно отправлять к компоненту (например, конечную точку для получения списка товаров в корзине), как их делать (например, запрос GET) и ожидаемые ответы.

В этом руководстве мы объединим эти две концепции для создания REST(ful) API, API, соответствующего ограничениям архитектурного стиля REST, с использованием Django REST Framework.< /p>

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

Django REST Framework (DRF) — это пакет, созданный на основе Django для создания веб-API. Одной из самых замечательных особенностей Django является его объектно-реляционный преобразователь (ORM), который облегчает взаимодействие с базой данных в стиле Python.

Однако мы не можем отправлять объекты Python по сети, поэтому нам нужен механизм для перевода моделей Django в другие форматы, такие как JSON, XML и наоборот. Этот иногда сложный процесс, также называемый сериализацией, очень упрощается с помощью Django REST Framework.

Примечание. Стоит отметить разницу между созданием REST API с помощью самого Django и с помощью Django REST.

Вы можете создавать классические веб-приложения с помощью Django и раскрывать их функциональные возможности миру с помощью REST API. На самом деле, это довольно легко сделать! Тем не менее, Django REST Framework более специализирован для этой задачи, построен на основе простого Django и упрощает процесс.

Если вы хотите узнать, как создавать REST API с помощью базовой среды Django, прочтите Руководство по созданию REST API в Python с помощью Django.

Настройка Django и нашего приложения

Django предназначен для проектов быстрой разработки приложений (RAD). Давайте быстро настроим проект Django:

Начнем с инициализации виртуальной среды для организации зависимостей и их влияния на другие зависимости и ее активации:

Затем мы можем установить Django и Django REST Framework в этой среде:

Наконец, мы можем создать проект и приложение под названием api_app :

После создания приложения его необходимо зарегистрировать в файле settings.py. Давайте представим его вместе с некоторыми встроенными приложениями, такими как admin и auth, которые упрощают функции администрирования и простую поддержку аутентификации.

Откройте файл в папке shopping_cart\settings.py и добавьте созданный нами каталог api_app в список INSTALLED_APPS. Кроме того, давайте добавим rest_framework в список, чтобы сообщить Django, что мы будем использовать Django REST Framework (отныне DRF):

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

Установив суперпользователя и зарегистрировав приложение, мы можем запустить сервер для приема запросов! Это легко сделать с помощью команды runserver из manage.py:

Процесс создания, настройки и настройки веб-приложения Django, а также основные компоненты веб-приложений Django (определение моделей, регистрация моделей, интерфейс администратора Django и т. д.) более подробно описаны в нашей Руководство по Core Django REST API.

Создание REST API в Django с использованием DRF

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

Модель домена

Давайте создадим простую модель CartItem для обозначения элемента корзины онлайн-покупателя или, скорее, продукта. В файле api_app/models.py мы определим нашу модель:

После определения мы зарегистрируем нашу модель в Django, чтобы иметь доступ к ней из панели администратора. Перейдите в api_app/admin.py и добавьте следующие строки:

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

Модель готова к использованию! Веб-приложения часто передают данные модели с одного конца на другой. Естественно, пришло время реализовать самую полезную функцию DRF — сериализаторы!

Сериализаторы определяют представление нашей модели в формате JSON и преобразуют экземпляры объектов в формат, более удобный для передачи. Это упростит парсинг данных для нашего API. Десериализаторы делают обратное — они преобразуют данные JSON в наши модели как экземпляры объектов.

Мы будем использовать сериализатор для преобразования объекта модели в формат JSON перед отправкой ответа.И когда мы получим запрос JSON, наш сериализатор преобразует его в объект модели, в данном случае CartItem.

Давайте создадим файл serializers.py в папке api_app и напишем ModelSerializer для нашей модели:

В файле models.py мы установили атрибут product_quantity нашей модели в качестве обязательного поля. Это гарантирует, что он всегда присутствует при сохранении объекта.

Однако, если пользователь не указал product_quantity, разумным предположением по умолчанию является то, что он хочет приобрести один товар. В этом случае API не должен выдавать ошибку и установить значение product_quantity равным 1 по умолчанию.

Сериализатор изящно справится с этим сценарием, и вам не придется писать какую-либо подобную логику в views.py. Вы можете просто добавить проверку и другие ограничения, необходимые для атрибута класса сериализатора.

По умолчанию для обязательного для каждого поля установлено значение True . Следовательно, сериализатор не продолжит работу, пока не получит их.

Класс APIView

Как и в случае с чистым Django, DRF поддерживает как представления на основе классов, так и представления на основе функций для API.

В этом руководстве мы отдаем предпочтение представлениям на основе классов.

Мы будем использовать класс APIView для представления представлений, который является подклассом класса View Django. Таким образом, мы получаем загрузочные методы post() , get() , patch() и delete() , которые мы можем использовать для легкого выполнения операций CRUD в нашей модели CartItem, вообще не вмешиваясь в уровень персистентности!

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

Методы get() , post() , patch() и delete() можно использовать в тандеме с методами модели, такими как all() , save() и delete(), чтобы упростить функциональность CRUD для приложения. .

Наш класс CartItemViews, представляющий представление, будет расширять APIView:

Создание объектов — обработчик запроса POST

Запрос POST используется для отправки данных на сервер, заключенных в теле запроса. Он предназначен для использования, когда вы хотите создать новые объекты. Давайте перейдем к нашим представлениям и создадим обработчик запроса POST для нашей модели CartItem.

Давайте перейдем к api_app/views.py, создадим новый класс с методом post(), который будет получать тело запроса POST, проверять его и создавать объект класса CartItem в нашей БД:

Здесь вы можете заметить, что сначала мы создали объект сериализатора из request.data, используя CartItemSerializer, который мы создали ранее. Функция is_valid() возвращает логическое значение, указывающее, можно ли использовать тело запроса для создания объекта CartItem. И метод save() создаст новый экземпляр CartItem .

Ответ должен быть инициализирован возвращаемыми данными. Эти данные могут быть экземпляром объекта Python любого типа, например bool , str , dict и т. д.

Давайте настроим и предоставим конечную точку для использования нашего метода post(). Для этого мы редактируем файл shopping_cart/urls.py и включаем открытые конечные точки нашего приложения:

После того, как конечная точка открыта, мы хотим зарегистрировать фактический класс CartItemViews в качестве представления для пользователя. Обратите внимание, что это не представление в смысле графического интерфейса — это обработчик запроса.

Мы включили здесь api_app.urls и делегировали логику, которая связывает представление со скриптом urls.py в api_app . В папке api_app создайте новый файл с именем urls.py и свяжите локатор cart-items/ с классом CartItemViews:

Первый аргумент path() — это подпуть, по которому будут доступны наши представления, а второй аргумент — это имя класса, который мы создали в views.py для обработки нашего запроса.

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

Давайте запустим приложение и воспользуемся нашей конечной точкой /api/cart-items/ :

На другом терминале давайте отправим POST-запрос на нашу конечную точку с некоторыми данными:

Представление обрабатывает входящий запрос и возвращает данные о продукте, а также статус:

Сериализатор принимает данные JSON, десериализует их в конкретный объект, а затем снова сериализует их, чтобы вернуть ответ.

Бесплатная электронная книга: Git Essentials

Ознакомьтесь с нашим практическим руководством по изучению Git, включающим передовые практики, общепринятые стандарты и памятку. Перестаньте гуглить команды Git и на самом деле изучите их!

Обратите внимание, что мы не создали никакую HTML-страницу, связанную с представлением, но DRF автоматически создал ее для нас:

Примечание. Если вы получили сообщение об ошибке "Шаблон не найден", убедитесь, что вы включили rest_framework в массив INSTALLED_APPS файла shopping_cart/settings.py .

В нем говорится, что метод GET не разрешен, потому что мы еще не создали обработчик GET для наших CartItemViews. Но есть поле ввода, которое позволит вам, тем не менее, отправить POST-запрос на конечную точку.

Запросить проверку данных

Что произойдет, если кто-то введет неверные данные? Например, строка для атрибута product_quantity, которая явно не соответствует ожидаемому типу данных?

Попробуем сделать неверный запрос к конечной точке API/cart-items :

Это приведет к ответу:

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

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

Если вы хотите узнать больше о валидаторах, прочитайте наше руководство по валидаторам Django (скоро!)

Получение объектов — обработчик запроса GET

Теперь, когда мы успешно добавили товар в корзину, давайте определим логику для извлечения этого объекта вместе с любыми другими объектами, которые могут быть в корзине.

Существует два типичных способа получения ресурсов:

Мы можем сделать запрос GET, чтобы получить список всех объектов, связанных с корзиной.
Мы можем получить определенный объект из нашей корзины, передав его идентификатор в качестве параметра URL.

Мы можем получить конкретный объект из модели и сериализовать его данные с помощью CartItemSerializer . Точно так же мы можем получить все объекты нашей модели и сериализовать их данные.

Последний подход требует передачи дополнительного аргумента, many :

Давайте ПОЛУЧИМ объект, учитывая его идентификатор и все остальные элементы в этой корзине, если идентификатор не был предоставлен, изменив файл api_app/views.py:

Если необязательный аргумент id опущен, запрос возвращает все элементы корзины вместо определенного, и в обоих случаях — ответ позволяет клиенту узнать, как прошел запрос, и сериализованные данные. вводится.

Давайте отправим GET-запрос нашей конечной точке API/cart-items/:

Это приведет к получению результатов в следующем виде:

Как видите, CartItemSerializer(items, many=True) возвратил сериализованные данные в формате JSON — список объектов. В качестве альтернативы мы можем предоставить аргумент id через URL, например, api/cart-items/1/ . Как только мы зарегистрируем конечную точку с переменным URL-адресом, подобным этому, DRF автоматически свяжет переменные пути с аргументами в нашем запросе.

Давайте теперь изменим urls.py приложения и добавим путь - cart-items/ , который также указывает на наш класс CartItemViews.

На этом этапе api_app/urls.py будет выглядеть следующим образом:

Теперь, когда мы достигаем конечной точки api/cart-items/1, переменная 1 преобразуется в аргумент id метода get():

Это приведет к следующему ответу:

Здесь вы можете заметить, что CartItemSerializer(item) вернул данные экземпляра CartItem в виде одного объекта JSON, а не массива, поскольку ожидается, что будет возвращен только один ресурс.

Обновление объектов — обработчик запроса PATCH

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

Для обновления объектов мы можем использовать POST-запросы, ориентированные на определенный идентификатор. Затем мы можем получить этот объект, обновить его и сохранить под тем же идентификатором, сохранив изменение.

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

Класс APIView предоставляет нам функцию patch(), которая обрабатывает запросы PATCH и обновляет данные.

Вновь вернемся к api_app/views.py, чтобы добавить обработчик запроса PATCH, как показано ниже:

Обратите внимание на эту строку:

Здесь мы передаем три аргумента нашему сериализатору.

Экземпляр модели CartItem, который мы хотим обновить.
Данные, полученные по запросу.
partial=True, чтобы указать, что это может не содержать все поля нашей модели CartItem .

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

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

И когда мы делаем обновление, мы проверим наш сериализатор, а затем сохраним его. Пришло время отправить запрос PATCH на api/cart-items/1 и обновить товар:

В результате:

Удаление объектов — обработчик запроса DELETE

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

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

Чтобы удалить товар из корзины, давайте реализуем функцию delete(), передав идентификатор объекта, который мы хотим удалить. Затем, вызвав метод delete() для самой модели, мы можем удалить ее из хранилища.

Для этой цели нам не потребуется использовать сериализатор, так как нет преобразования между данными и конкретными объектами. Вместо CartItem.objects.get() мы можем использовать функцию get_object_or_404(), которая автоматически вернет ответ 404, когда объект с заданным идентификатором отсутствует, поскольку мы не будем возвращать никакой информации о самом удаленном объекте. .

Таким образом, мы знаем, существует ли объект (не вернул 404 ) или нет, без необходимости его сериализации и отправки обратно в качестве ответа.

Вернемся к api_app/views.py и добавим метод delete():

Не пропустите новое заявление об импорте! После того, как мы получим объект, вызов его метода delete() удалит его из базы данных.

Попробуем удалить товар из нашей корзины:

Если элемент присутствует, функция должна вернуть следующий ответ:

Если элемент отсутствует, ответ будет выглядеть следующим образом:

Заключение

В этом руководстве показано, как мы можем создать RESTful API в Django с помощью Django REST Framework. Мы создали проект Django и добавили в него приложение api_app. Затем мы создали модель CartItem и CartItemSerializer для обработки сериализации и десериализации нашей модели.

Мы добавили представление CartItemView на основе классов для выполнения операций CRUD в нашей модели. Мы добавили товар в корзину с помощью post(), мы получили все товары и конкретный товар с помощью get(). Мы также создали patch() для обновления наших товаров и delete() для удаления товара из корзины.

Давайте посмотрим, как создать RESTFul API для нашего проекта Django Talk с помощью Django Rest Framework (DRF) — приложения, используемого для быстрого создания RESTful API на основе моделей Django.

Иными словами, мы будем преобразовывать не-RESTful-приложение в RESTful-приложение с DRF. Для этого приложения мы будем использовать DRF версии 2.4.2.

Это руководство охватывает следующие темы:

Настройка DRF
Структура REST
Сериализатор модели
API DRF для просмотра в Интернете

Бесплатный бонус: нажмите здесь, чтобы загрузить копию руководства «Примеры REST API» и получить практическое введение в принципы Python + REST API с практическими примерами.

Если вы пропустили первую и вторую части этой серии руководств, обязательно ознакомьтесь с ними. Нужен код? Загрузите его из репозитория. Чтобы получить более подробное руководство по Django Rest Framework, ознакомьтесь с третьим курсом Real Python.

Настройка DRF

Структура REST

< tr> td>

GET	POST	PUT	DELETE
/posts/	Показать все сообщения	Добавить новое сообщение	Обновить все сообщения	Удалить все сообщения
/posts/	Показать	Н/Д	Обновить	Удалить идентификатор

Быстрый старт DRF

Давайте запустим наш новый API!

Сериализатор модели

Сериализаторы DRF преобразуют экземпляры моделей в словари Python, которые затем могут отображаться в различных форматах, подходящих для API, таких как JSON или XML. Подобно классу Django ModelForm, DRF поставляется с кратким форматом для своих сериализаторов — классом ModelSerializer. Он прост в использовании: просто укажите, какие поля из модели вы хотите использовать:

Сохраните это как serializers.py в папке «talk».

Обновить представления

Нам нужно реорганизовать наши текущие представления, чтобы они соответствовали парадигме RESTful. Закомментируйте текущие представления и добавьте:

Обязательно прочтите дополнительную информацию о @api_view в официальной документации.

Обновить URL

Давайте подключим несколько новых URL:

Теперь мы готовы к нашему первому тесту!

Итак, без дополнительной работы с нашей стороны мы автоматически получаем этот приятный, удобочитаемый вывод нашего API. Хороший! Это огромная победа DRF.

Прежде чем двигаться дальше, вы, возможно, заметили, что поле автора представляет собой идентификатор, а не фактическое имя пользователя. Мы рассмотрим это в ближайшее время. А пока давайте подключим наш новый API, чтобы он работал с шаблонами нашего текущего приложения.

Рефакторинг REST

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

Все это вы уже видели. Обратите внимание, как мы обрабатываем успех: поскольку API отправляет обратно несколько объектов, нам нужно перебирать их, добавляя каждый в DOM. Мы также изменили json[i].postpk на json[i].id при сериализации идентификатора сообщения .

Проверьте это. Запустите сервер, войдите в систему и проверьте сообщения.

Помимо автора, отображаемого в виде идентификатора, обратите внимание на формат даты и времени. Это не то, чего мы хотим, верно? Нам нужен удобочитаемый формат даты и времени. Давайте обновим это…

Формат даты и времени

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

Во-первых, нам нужно импортировать библиотеку в наш файл index.html:

Затем обновите цикл for в main.js:

Здесь мы передаем строку даты в новую функцию convert_to_readable_date() , которую необходимо добавить:

Вот и все. Обновите браузер. Формат даты и времени теперь должен выглядеть примерно так — 22.08.2014, 18:48:29. Обязательно ознакомьтесь с документацией MomentJS, чтобы получить дополнительную информацию об анализе и форматировании строки даты и времени в JavaScript.

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

Обновите функцию post_collection() в views.py:

Также добавьте следующий импорт:

Обновите конечную точку в функции create_post()

Протестируйте его в браузере. Он должен работать. Не забудьте правильно обновить обработку дат, а также изменить json.postpk на json.id :

Формат автора

Сейчас самое время сделать паузу и решить проблему с идентификатором автора и именем пользователя. У нас есть несколько вариантов:

Будьте действительно СПОКОЙНЫ и сделайте еще один звонок, чтобы получить информацию о пользователе, что не очень хорошо для производительности.
Используйте отношение SlugRelatedField.

Давайте выберем последний вариант. Обновите сериализатор:

Что здесь происходит?

SlugRelatedField позволяет нам изменить цель поля автора с идентификатора на имя пользователя.
Кроме того, по умолчанию целевое поле — имя пользователя — доступно как для чтения, так и для записи, поэтому стандартное отношение будет работать как для запросов GET, так и для запросов POST.

Также обновите переменную данных в представлениях:

Проверьте еще раз. Теперь вы должны увидеть имя пользователя автора. Убедитесь, что запросы GET и POST работают правильно.

Удалить

Прежде чем что-то изменить или добавить, проверьте это. Попробуйте удалить ссылку. Что просходит? Вы должны получить ошибку 404. Любая идея, почему это было бы? Или куда обратиться, чтобы узнать, в чем дело? Как насчет функции delete_post в нашем файле JavaScript:

Такого URL не существует. Прежде чем мы его обновим, спросите себя: «Должны ли мы ориентироваться на коллекцию или на отдельный элемент?». Если вы не уверены, прокрутите страницу назад и просмотрите таблицу RESTful Structure. Если мы не хотим удалять все сообщения, нам нужно нажать на конечную точку элемента:

Проверьте еще раз. Что теперь происходит? Вы должны увидеть ошибку 405 — 405: — поскольку представление не настроено для обработки запроса DELETE.

Заключение и следующие шаги

На этом пока все. Нужен дополнительный вызов? Добавьте возможность обновлять записи с помощью запроса PUT.

Фактическая часть REST проста: вам просто нужно обновить функцию post_element() для обработки запросов PUT.

Клиентская сторона немного сложнее, так как вам нужно обновить фактический HTML, чтобы отобразить поле ввода, в котором пользователь может ввести новое значение, которое вам нужно будет получить в файле JavaScript, чтобы вы могли его отправить. с запросом PUT.

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

Если да, то собираетесь ли вы обновить имя автора? Может быть, добавить поле edited_by в базу данных? Затем также отобразите отредактированную заметку в DOM. Если пользователи могут обновлять только свои собственные сообщения, вам нужно убедиться, что вы правильно обрабатываете это в представлениях, а затем отображаете сообщение об ошибке, если пользователь пытается отредактировать сообщение, которое он/она изначально не публиковал.

Или, возможно, вы могли бы просто удалить ссылку редактирования (и, возможно, также ссылку удаления) для сообщений, которые определенный пользователь не может редактировать. Вы можете превратить это в проблему с разрешениями и позволить только определенным пользователям, например модераторам или администраторам, редактировать все сообщения, в то время как остальные пользователи могут обновлять только свои собственные сообщения.

Так много вопросов.

В любом случае, в следующий раз вы увидите, как мы разбираем текущий код JavaScript по мере добавления в Angular! Тогда увидимся.

Раз в несколько дней получайте короткие и интересные трюки с Python. Никакого спама никогда. Отписаться в любое время. Куратор: команда Real Python.

Освойте навыки работы с Python в реальном мире с неограниченным доступом к реальному Python

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

Освойте навыки работы с Python в реальном мире
с неограниченным доступом к реальному Python

Что вы думаете?

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

Если вы думаете, что Django творит чудеса, потому что вы можете сделать так много всего несколькими строками, подождите, пока вы не узнаете, что такое Django Rest Framework.

Что такое API?

Django Rest Framework позволяет создавать RESTful API: простой способ передачи информации между интерфейсом и базой данных.

Он разделяет пользовательский интерфейс и хранилище данных и связывает пользователя и базу данных, отправляя файл .json. Как и этот:

Встроенный визуальный интерфейс DRF

Вспомните, когда вы в последний раз делали покупки в Интернете: помните ли вы, что каждая статья имела одинаковую структуру, но содержала разную информацию?

Они создали структуру с помощью HTML и CSS, а затем использовали API для заполнения каждой статьи.

Зачем использовать API?

Вы не сможете понять, что такое API, если не поймете, что он может делать.

Представьте, что вы хотите создать веб-приложение. Очевидно, вы бы выбрали Django.

Вы создаете его, и он становится хитом! Всем нравится ваше веб-приложение!

Они так любят его, что хотят версию для мобильных телефонов!

Пришло время создать версию для Android! И версия для iOS.

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

Это открывает двери для многих возможных ошибок…

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

Теперь вы заметили, что ваш сайт статичен. Вы хотите, чтобы ваше веб-приложение было более динамичным и современным. Для этого вам нужен Javascript.

Хотя вы можете сделать это только с помощью Vanilla Javascript, лучше использовать среду JS, такую как React или Vue.

Теперь вам снова нужно повторить то, что вы делали в Django, iOS и Android.

Или вы можете создать REST API.

С помощью DRF вы можете создать API для передачи информации в пользовательский интерфейс.

Вы можете создать FrontEnd с Vue, приложением для Android и iOS, и все три разные платформы подключены к одному и тому же API

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

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

Так проще, правда? Проще, масштабируемее и надежнее.

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

Почему Django Rest Framework?

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

Но зачем использовать Django Rest Framework, а не Node.js, Golang, Rust и т. д.?

Ну, для начала, DRF использует Python, простой для изучения язык.

DRF, как и Django, делает все проще и проще.Знаете ли вы представления Django? Они есть и в DRF!

Вот и все. Вы создаете класс с именем UserList, который наследует методы от ListCreateAPIView.

Как следует из названия, вы можете перечислять и создавать пользователей. Если вы запросите URL-адрес (GET), вы получите список пользователей, если вы отправите (POST) информацию на этот URL-адрес, будет создан новый пользователь.

3 строки кода. Это все, что вам нужно.

Еще одна замечательная особенность DRF? Его документация. Наряду со Scrapy у него лучшая документация по Django Framework, которую я когда-либо видел.

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

Будьте уверены, вы не ошибетесь, выбрав Django Rest Framework.

Как изучить Django Rest Framework

Хорошо Дэвид , я согласен. Я хочу изучить Django Rest Framework прямо сейчас, чтобы легко взаимодействовать с моей базой данных. Как я могу изучить DRF?

Хороший вопрос! Помимо простоты использования, у вас есть много бесплатных ресурсов для изучения:

Удобная для начинающих версия официального руководства по Django REST Framework, статья Уильяма Висента, статья на Medium

Заключение

Подытожим все, что мы сегодня узнали о Rest API и Django Framework:

REST API позволяют нам обмениваться информацией между интерфейсом и базой данных.
Мы можем использовать один REST API для поддержки любой платформы, которую захотим. Это устраняет дублирование кода и облегчает его эскалацию.
DRF использует Python, язык, который легко освоить.
Благодаря использованию Python и структуре DRF нам нужно всего несколько строк, чтобы что-то сделать.
Документация отличная
В Интернете есть множество бесплатных ресурсов
Отличный встроенный интерфейс.

Если вам нужно отправлять и получать данные между мобильным или веб-приложением, вы не ошибетесь с Django Rest Framework.

API (интерфейс прикладного программирования) – это программное обеспечение, позволяющее двум приложениям взаимодействовать друг с другом.

В этом руководстве мы рассмотрим различные способы создания API Django Rest Framework (DFR). Мы создадим приложение Django REST с Django 2.X.X, которое позволит пользователям создавать, редактировать и удалять API.

Почему DRF:

Среда Django REST — это мощный и гибкий набор инструментов для создания веб-API.

Некоторые причины, по которым вам может понадобиться REST framework:

API с возможностью просмотра веб-страниц — это огромное преимущество для ваших разработчиков.
Политики аутентификации, включая пакеты для OAuth1a и OAuth2.
Сериализация, поддерживающая как ORM, так и другие источники данных.
Всю индивидуальную настройку — просто используйте обычные представления на основе функций, если вам не нужны более мощные функции.
Обширная документация и отличная поддержка сообщества.
Используется и пользуется доверием всемирно признанных компаний, включая Mozilla, Red Hat, Heroku и Eventbrite.

Традиционно Django известен многим разработчикам как MVC Web Framework, но его также можно использовать для создания серверной части, которая в данном случае является API. Посмотрим, как вы сможете создать с его помощью серверную часть.

Начнем

В этом блоге вы будете создавать простой API для простой службы управления сотрудниками.

Настройте среду разработки:

Пожалуйста, установите Python 3. Здесь я использую Python 3.7.3

Вы можете проверить свою версию Python с помощью команды

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

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

Создайте каталог «Управление сотрудниками» и используйте этот каталог

Это активирует виртуальную среду, которую вы только что создали.

Давайте установим Django и djangorestframework в вашу виртуальную среду.

Я буду устанавливать Django 2.2.3 и djangorestframework 3.9.4

Начать проект:

После настройки среды разработки давайте запустим проект Django. Я создаю проект с именем API

Теперь создайте приложение Django. Я создаю приложение для сотрудников

Теперь у вас будет такая структура каталогов:

Теперь приложение и проект созданы. Теперь мы будем синхронизировать базу данных. По умолчанию Django использует sqlite3 в качестве базы данных.

Если вы откроете api/settings.py, вы заметите следующее:

Вы можете изменить механизм БД в соответствии с вашими потребностями. Например, PostgreSQL и т. д.

Мы создадим начального пользователя-администратора и установим пароль для использования.

Давайте добавим ваше приложение в качестве API, откройте файл api/settings.py и добавьте приложения rest_framework и employee в INSTALLED_APPS.

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

TDD – разработка тестовых драйверов

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

Давайте напишем тест для сотрудников/конечной точки GET

Давайте создадим тест для конечной точки, который возвращает все песни: GET employee/.

Откройте файл employee/tests.py и добавьте следующие строки кода;

Добавьте этот код в git и сделайте основную ссылку

А пока давайте прикрепим скриншоты:

Пока не пытайтесь запускать этот код. Мы еще не добавили код представления или модели. Теперь добавим вид.

Добавить представление для сотрудников/конечной точки GET

Теперь мы добавим код представления, которое будет отвечать на запрос GET сотрудников/.

Модель. Сначала добавьте модель, в которой будут храниться данные о сотрудниках, которые будут возвращены в ответе. Откройте файл employee /models.py и следующие строки кода.

Мы добавим нашу модель в админку. Это поможет в управлении административной частью сотрудников. Например, добавить/удалить сотрудника через пользовательский интерфейс администратора. Давайте добавим следующие строки кода в файл сотрудников /admin.py.

Теперь запустите make миграции из командной строки

Теперь запустите команду миграции. Это создаст таблицу сотрудников в вашей БД.

Сериализатор: добавьте сериализатор. Сериализаторы позволяют преобразовывать сложные данные, такие как наборы запросов и экземпляры моделей, в собственные типы данных Python, которые затем можно легко преобразовать в JSON, XML или другие типы контента.

Добавьте новый файл employee/serializers.py и добавьте следующие строки кода;

Сериализаторы также обеспечивают десериализацию, позволяя преобразовывать проанализированные данные обратно в сложные типы после предварительной проверки входящих данных. Сериализаторы в среде REST работают очень похоже на классы Django Form и ModelForm.

Просмотр. Наконец, добавьте представление, которое возвращает все песни. Откройте файл employee/views.py и следующие строки кода;

Здесь указано, как получить объекты из базы данных, установив атрибут queryset класса и указав сериализатор, который будет использоваться при сериализации и десериализации данных.

Представление в этом коде наследуется от универсального набора представлений ListViewSet