Часть 2: REST API, приложения и Django REST фреймворк

В этом (достаточно большом) разделе рассматриваются HTTP протокол, REST, Django приложения (как понятие), представления, URL-адреса и основы Django REST фреймворка.

Введение

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

После того как Вы прочитали эти части и выполнили действия, указанные в них, у нас есть прочный фундамент для нашего приложения, готовый для дальнейших модификаций. Эта часть начинается с краткого курса по HTTP. Затем поясняется понятие "приложения" в Django. Наконец, большая часть этого раздела посвящена краткому введению в Django REST фреймворк.

После пояснения основных понятий, мы рассмотрим некоторые ключевые функции Django REST фреймворка. Они будут использоваться при создания API приложения для работы со встроенной моделью User. Одновременно с этим мы научимся взаимодействовать с REST API в терминале.

Используемые технологии

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

Django приложения: "Под термином "приложение" понимается Python пакет, предоставляющий некоторый набор функций. Приложения могут повторно использоваться в различных проектах" (источник). Django проект состоит из множества Приложений, которые можно повторно использовать в других проектах. Более подробно Django приложения мы рассмотрим ниже.
HTTP. Сокращение от Hypertext Transfer Protocol (протокол передачи гипертекста). HTTP является протоколом передачи данных по схеме "запрос-ответ" в модели клиент-сервер (источник).
HTTP методы/действия: Методы, как определено в HTTP стандартах, "указывают на желаемую операцию, которая должна быть выполнена над ресурсом" (источник). Основными методами являются GET и POST. Существуют и другие, например, DELETE, PUT, PATCH и т. д. Конкретный URL-адрес может выполнять различные функции в зависимости от метода, переданного ему в HTTP-запросе.
RESTful. Сокращение от Representational State Transfer (репрезентативная передача состояния). "Веб-службы, совместимые с REST, позволяют запрашивающим системам получать доступ к текстовым представлениям веб-ресурсов и манипулировать ими, используя единый и предопределенный набор операций, не зависящих от предыдущего состояния ресурсов" (источник). Это означает, что REST приложения имеют стандартный набор/структуру HTTP ресурсов, предоставляющих данные клиентам с сервера, в зависимости от используемого HTTP метода.
Django REST фреймворк: "Django REST фреймворк - это мощный и гибкий инструментарий для создания Web API" (источник). Мы будем использовать приложение Django REST фреймворк, чтобы облегчить интегрирование REST API в существующий функционал Django!

Подробное пошаговое руководство

1. Краткий курс по HTTP и REST

Глубоко не вникая в принципы построения сетей, я поясню HTTP (протокол передачи гипертекста).

1-A. Принцип работы Интернета, используя уровни модели OSI

В концептуальную модель, используемую в Интернет, (Internet Protocol Suite) входят четыре больших уровня. А именно:

Прикладной уровень
Транспортный уровень
Интернет уровень
Канальный уровень

HTTP (протокол передачи гипертекста) - это структура для хранения "данных". Он находится в самом верхнем уровне - прикладном уровне. Он перемещается по Интернету с помощью транспортного уровня. наиболее часто используемыми технологиями транспортного уровня являются TCP и UDP. TCP/UDP пакеты содержат в себе HTTP и перемещаются благодаря Интернету и канальному уровню. Чтобы лучше понять как работают сети и Интернет, изучите 7-уровневую модель OSI.

1-B. URLы и ресурсы

Доступ к HTTP обычно осуществляется с помощью HTTP URI. URI - это Uniform Resource Identifier (унифицированный идентификатор ресурса). URL - (Uniform Resource Locator - единообразный локатор ресурса) - это особый тип URI, который используется для идентификации веб-адреса. Поэтому, когда мы говорим о ссылке, например, https://www.instagram.com/, мы говорим о HTTP ресурсе. Таким образом, HTTP URI, принимает форму HTTP URL.

Мы используем URLы для определения HTTP ресурсов доступных нам. Их назначение должно быть понятно из названия! Например, https://www.instagram.com/accounts/login/ описывает ресурс, позволяющий пользователю войти в систему.

1-C. HTTP запросы и ответы

HTTP ресурсы предоставляются через запросы и ответы. HTTP запрос указывает - "дай мне это" или "сделай это " серверу. Сервер будет выполнять определенную последовательность процессов, основываясь на данных запроса, определяя какие функции должны быть вызваны и какие данные должны быть возвращены. Как только это процессы будут завершены, сервер посылает обратно HTTP ответ. В этом ответе сообщается - "я сделал это" или "вот <ресурс>, который был запрошен" кроме стандартных сообщений об успешном выполнении запроса или возникшей ошибки.

1.4 HTTP методы

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

Наиболее важными HTTP методами являются GET и POST.

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

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

Чтобы показать как HTTP ресурс может работать с различными типами HTTP запросов + различными комбинациями метода, мы будем использовать пример URL-адреса из Instagram:

https://www.instagram.com/media/<media-id>/likes

Документацию к этому API можно найти здесь.

Этот URL-адрес позволяет нам выполнять операции с лайками фото или видео пользователя. Выполняя HTTP запросы, используя разные методы, к этому URL-адресу можно осуществлять различные операции:

Запрос с методом GET: возвратит список всех лайков для медиа-ресурса
Запрос с методом POST: позволит текущему пользователю лайкнуть медиа-ресурс

1.5 Коды состояния

После обработки запроса сервер пытается отправить HTTP-ответ клиенту. Начало ответа будет содержать код состояния результата запроса.

В Википедии утверждается, что коды состояний делятся на пять основных различных классов (источник). Эти классы и случаи, когда такой код состояния возвращается, приведены ниже:

Информационные (1XX): Вряд ли Вы часто будете встречаться с кодом состояния 1XX
Успешные (2XX): 200 OK (возвращается при успешном получении страницы)
Перенаправление (3XX): 304 Не изменился (закэшированный CSS файл не изменился)
Ошибка клиента (4XX): 404 Не найдено (страница не найдена)
Ошибка сервера (5XX): 500 Внутренняя ошибка сервера (общая ошибка)

При использовании команды manage.py runserver Вы увидите запросы, методы, ответы и коды статуса , отображающиеся в терминале! Два GET запроса/ответа показаны ниже. Один вернул внутреннюю ошибку сервера с кодом 500, а другой - 200 код при обращении к URL главной страницы.

Пример двух GET запросов/ответов

1.6 RESTful API

HTTP-ресурс из Instragram, используемый ранее, - это часть их RESTful API!

https://www.instagram.com/media/<media-id>/likes

Как было сказано выше, REST - это сокращение от репрезентативной передачи состояния. RESTful API - это структурированный набор HTTP-ресурсов. Эти ресурсы описывают функции/модели базы данных и выполняют манипуляции над этими ресурсами с помощью набора стандартных HTTP-запросов.

Эти стандарты определяют как должны быть структурированы URL-адреса и какие функции должны выполняться , основываясь на заданных HTTP методах. RESTful API должно быть структурировано таким образом, чтобы все ресурсы представляли модель данных. Назначение методов, поддерживаемых ресурсом, должно быть очевидно из названия. Метод GET при обращении к ресурсу должен возвращать все значения модели, связанной с этим ресурсом, например, обращение к ресурсу users/ должно возвращать всех пользователей в базе данных. Если указано значение первичного ключа (т. е. конкретного отношения в базе данных), то нужно возвращать только данные этого пользователя users/1/. В то же время, обращение к этому же ресурсу методом POST потребует передачи необходимых данных для создания пользователя. Использование метода POST для ресурса users/1/ позволит обновить данные для пользователя с первичным ключом 1. ** Существует ряд других особенностей, которые мы рассмотрим при написании API!

Мы должны структурировать все наши URL-адреса так, чтобы они соответствовали моделям в нашей базе данных, чтобы сделать наше приложение максимально RESTful! Мы НЕ должны создавать ресурсы, которые при обращении к ним, предоставляют доступ к произвольным функциям.

** При написании реальных приложений мы будем использовать методы PUT или PATCH для этих типов функций. Но сейчас мы рассматриваем базовые принципы написания RESTful API.

1.7 Резюме

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

2. Введение в Django приложения

Возвращаемся к Django! Сейчас важно уяснить такое понятие как Django приложение, прежде, чем мы создадим ещё одно.

“Но мы же не использовали команду `manage.py startapp` ?” — начинающий разработчик

Как описано в документации, Django приложения - это "Python пакет, предоставляющий некоторый набор функций", с возможностью многократного использования и представляющий собой "комбинацию моделей, представлений, шаблонов, ..., URL-адресов и т. д.".

Прочитайте определение ещё раз.

Python пакет, предоставляющий некоторый набор функций

Из этого утверждения можно сделать вывод, что: мы уже создали Django приложение! Им являются файлы в каталоге config. Любой Python пакет, предоставляющий некоторый набор функций, является приложением. "Проект" - это приложение. Важно различать понятие Django проекта и Django приложения. Это совершенно разные вещи. Понятие "проекта" описывается в документации следующим образом:

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

С учётом этого определения, проект в Django сам по себе представляет не что иное как по-другому структурированное приложение с возможностью многократного использования. Все приложения, которые мы создаём должны быть многократно используемыми! Это означает, что если мы создали API приложение , то мы всегда можем скопировать этот код в другой понравившийся нам "проект" и оно должно работать! Справедливо и обратное утверждение! У нас может быть "проект" (например, тот, который мы только что создали), с которым может работать любое правильно настроенное приложение!

Приложение "проект" является менеджером или управляющим, позволяющим сторонним/самописным приложениям взаимодействовать с Django библиотеками. Эти взаимодействия возможны благодаря классу AppConfig (документация, источник). Файл с настройками знает о других приложениях и их функциях, потому что использует AppConfig, который обычно находится в файле app.py по умолчанию. После добавления названия каталога в INSTALLED_APPS, сначала происходит поиск файла app.py в этом каталоге для настройки приложения (класс AppConfig может находиться в другом файле, но мы предполагаем, что используется структура, по умолчанию применяемая командой manage.py startapp).

Сейчас мы создадим другое приложение, используя команду startapp (источник). Структура приложения, используя команду startapp будет иметь вид:

app
├── __init__.py 
├── admin.py            # Добавляет модели из этого приложения в приложение Admin
├── apps.py             # Точка входа в этого приложение
├── migrations          # Определяет изменения в базе данных, возникших после создания моделей
│   ├── __init__.py
├── models.py           # Связи между таблицами в базе данных, используемые этим приложением
├── tests.py            # Тесты, которые нужно запускать для этого приложения
└── views.py            # Функции, выдающие данные модели/пользовательские данные

Большинство Django приложений содержат urls.py, файлы с миграциями, и каталоги, такие как templates и static.

Именно отсюда добавляются новые таблицы в нашу базу данных, когда мы изменяем models.py. Данные, созданные с помощью классов в файле models.py обрабатываются и передаются в HTTP ответе от сервера, благодаря views.py. urls.py осуществляет маршрутизацию HTTP-запросов, поручая их обработку соответствующим представлениям.

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

3. Введение в Django REST фреймворк

Теперь когда нам понятен принцип построения Django приложений, мы кратко рассмотрим Django REST фреймворк (DRF). DRF - это стороннее приложение, которое мы будем использовать в связке с нашим приложением для создания REST API. Оно предоставляет нам множество функций, сильно связанных с существующими структурами в Django, помогая нам создавать RESTful HTTP ресурсы, соответствующие моделям, спроектированными нами! Мы будем использовать DRF для:

создания URL-адресов;
обработки данных , используя обобщенные представления и ViewSets;
аутентификации пользователей;
проверки прав доступа;
удобной выдачи информации , предоставляемой нашим API.

Мы познакомимся с особенностями Django REST фреймворка и подробно поясним каждую, когда начнём работать с ним!

На этом теоретическая часть заканчивается! Давайте добавим API приложение!

"Вот где начинается всё самое интересное" - Мем из приквела к Звездным Воинам

4. Добавление приложений, предназначенных не для настройки проекта

Чтобы не нарушать структуру нашего проекта, мы создадим каталог в корневом каталоге с названием project. Внутрь этого каталога мы будем добавлять другие наши приложения. Создайте каталог, а затем перейдите в него:

# Команды
mkdir project
cd project/

Затем мы используем команду startapp для создания приложения с названием api внутри этого каталога.

# Команда
python ../manage.py startapp api

Наш каталог api должен выглядеть следующим образом:

api/
├── __init__.py
├── admin.py
├── apps.py
├── migrations
│   └── __init__.py
├── models.py
├── tests.py
└── views.py

Теперь, когда приложение создано, создадим urls.py. Сначала создайте файл:

# Команда
touch project/api/urls.py

Затем мы импортируем функции, необходимые для создания URL файла, чтобы Django не выдал ошибку:

from django.conf.urls import url, include

urlpatterns = [
]

Теперь мы должны сообщить config о нашем новом приложении. Для этого добавим необходимые изменения в config/settings/base.py и config/urls.py. В base.py добавьте приложение api в LOCAL_APPS.

LOCAL_APPS = (
    'project.api',
)

Оно должно подхватиться автоматически благодаря api.app.AppConfig!

Теперь мы можем добавить URL-адреса из приложения api к основным URL-адресам из файла config/urls.py. URL-адреса приложения api будут доступны из корня сайта, поскольку в конце концов мы создаём API сервер.

Добавьте следующие изменения в config/urls.py:

from django.conf.urls import include, url
from django.contrib import admin
urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^', include('project.api.urls')),
]

Мы импортировали django.conf.urls.include и использовали его для добавления файла api/urls.py.

6. Устанавливаем и настраиваем Django REST фреймворк

Теперь, когда приложение создано, нам необходимо установить Django REST фреймворк, добавить его настройки в config/settings/base.py и внести необходимые изменения.

6-1. Устанавливаем Django REST фреймворк

Добавьте следующее в requirements/base.txt:

djangorestframework==3.6.2

Затем установите эту зависимость с помощью стандартной команды:

# Команда
pip install -Ur requirements/local.txt
# Ожидаемый результат
...
Successfully installed djangorestframework-3.6.2

6-2. Настраиваем Django REST фреймворк

В config/settings/base.py мы должны добавить Django REST фреймворк в INSTALLED_APPS и настроить его.

В THIRD_PARTY_APPS добавьте rest_framework:

THIRD_PARTY_APPS = (
    'rest_framework',
)

В конец файла base.py добавьте следующее:

REST_FRAMEWORK = {
}

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

В настоящий момент мы уже можем использовать Django REST фреймворк. Но мы пока не создали никакого API.

Теперь мы добавим базовые конечные точки для модели User, определенные в руководстве по быстрому старту на сайте Django REST фреймворка. Эти ресурсы позволят администраторам вносить изменения в модель User. Позднее мы внесём в неё изменения (кто-то слышал об аутентификации с помощью токенов?), но пока важно рассмотреть/показать простоту использования DRF!

7. Сериализаторы

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

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

Сериализаторы в REST фреймворке работают подобно Django классам Form и ModelForm. Мы предоставляем Вам класс Serializer, который является мощным и обобщенным средством, позволяющим управлять видом ответа от сервера, а также класс ModelSerializer, который может служить полезной альтернативой при создании сериализаторов, работающих с экземплярами моделей и запросами.

Учитывая это определение, мы можем использовать сериализаторы для двух основных целей:

Извлечение данных модели из базы данных в формате JSON
Использование их подобно формам для проверки данных и создания экземпляра модели

Существуют различные типы сериализаторов, но сейчас мы рассмотрим HyperlinkedModelSerializers. Чтобы понять как их использовать, давайте сначала рассмотрим ModelSerializers:

Класс ModelSerializer отличается от обычного класса Serializer тем, что:

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

Он автоматически генерирует валидаторы для сериализатора, например, unique_together валидаторы.

Он содержит простые используемые по умолчанию реализации методов .create() и .update().

HyperlinkedModelSerializers создают на основе ModelSerializers, используя URL-адрес вместо значений первичного ключа для определения отношений. Таким образом, при получении данных из сериализатора вы получите поле url вместо pk.

Всё это можно сделать вручную, однако нам стоит использовать HyperlinkedModelSerializer в 9 случаях из 10 при работе с моделью. В более сложных ситуациях возможно нам придется создавать весь Serializer вручную.

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

Теперь мы создадим наш сериализатор для модели User. Сначала создайте serializers.py:

# Команда
touch project/api/serializers.py

В файл project/api/serializers.py мы добавим класс UserSerializer:

from django.contrib.auth.models import User
from rest_framework import serializers
class UserSerializer(serializers.HyperlinkedModelSerializer):
    class Meta:
        model = User
        fields = ('url', 'username', 'email', 'groups')

Мы импортировали модель User и создали HyperlinkedModelSerializer, который извлечёт данные, связанные с моделью, а также URL-адрес экземпляра модели.

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

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

Теперь мы создадим представление, которое позволит при обращении по URL-адресу извлекать данные из сериализатора и возвращать эти данные пользователю/конечной точке. Для этого нам нужно понять, что такое представления, представления-классы и ViewSetы.

8-1. Представления

Во-первых, нужно понять что такое представление. Оно определяется в Django как:

Преставление-функция или просто представление - это всего навсего Python функция, получающая Web-запрос и возвращающая Web-ответ.

Хорошо, что мы уже знаем о HTTP запросах и ответах!

Представления, кроме всего прочего, "отвечают за сопоставление с URL-адресами, обработку различных HTTP методов (GET, POST и т.д.)".

8-2. Представления-классы

Большинство начинающих Django разработчиков пишут очень много представлений с нуля. О таком понятии как представления-классы они или не слышали (да, это понятие не достаточно хорошо описано в документации, поэтому не все используют его с самого начала) или боятся его использовать. Однако четкое определение того, чем являются представления-классы даётся на сайте Classy Class-Based Views:

"Обобщенные представления-классы в Django - это абстрактные классы, реализующие наиболее часто встречающиеся задачи в веб-разработке. Они очень эффективны и активно используют объектно- ориентированный принцип языка Python и множественное наследование, благодаря чему являются легко расширяемыми. Таким образом, они представляют собой не просто набор обобщенных функций, а инструментарий, который можно использовать при создании намного более сложных представлений, написанных Вами."

Classy Class-Based Views - это наверное самый лучший сайт, содержащий документацию, необходимую для работы с представлениями-классами. Используйте его. ПОДЕЛИТЕСЬ ССЫЛКОЙ НА НЕГО. Для каждого обобщенного класса на сайте указано какие атрибуты и методы можно переопределить. Когда Вы хорошо изучите документацию, предоставленную на этом сайте, Вам станет намного проще исправлять ошибки, возникающие при переопределении значений, используемых по умолчанию.

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

**Если будет много комментариев, связанных с представлениями-классами, я могу написать отдельную статью по этой теме.

Чтобы узнать больше о представлениях-классах воспользуйтесь этой ссылкой:

Введение в представления-классы из Django документации.

8-3. Обобщенные представления и ViewSetы Django REST фреймворка

Так же как у Django есть свои стандартные представления-классы, у Django REST фреймворка тоже есть свои. Опять же не стоит придумывать велосипед и заново реализовывать функции многие из которых уже написаны и доступны во фреймворке. Вы можете легко с нуля написать представление, используя DRF или расширить предоставляемые фреймворком обобщенные представления. Обобщенные представления DRF описаны здесь.

Мы будем использовать обобщенные представления для написания своих, пользовательских функций API! Однако чаще всего мы будем использовать ViewSetы.

ViewSetы определяются в DRF следующим образом:

"разновидность представления-класса, в котором не реализованы обработчики ни одного из HTTP методов, например, get() или post(), зато вместо них реализованы такие методы-действия как .list() и .create()."

Это означает, что многие из представлений, которые нам пришлось бы создавать с помощью обобщенных представлений, теперь объединены в одно! Другой важной причиной использования ViewSetов является то, что в сочетании с DRF-маршрутизаторами (о них чуть позже), URL-адреса для наших ресурсов создаются автоматически!

Ссылки с описанием представлений-классов, ViewSetов и сериализаторов , предоставляемых DRF, также можно найти на сайте Classy Django REST Framework.

8-4. Создаём ViewSet для нашей модели User

Теперь, когда мы закончили рассмотрение такого понятия как представление, пора создать ViewSet для нашей модели User. Мы создадим UserViewSet наследуясь от класса ModelViewSet.

Из документации видно, что в классе ModelViewSet описаны следующие методы: .list(), .retrieve(), .create(),

.update(),.partial_update() и .destroy(). Таким образом, реализовывать эти функции самостоятельно нам не нужно! Тем не менее, нам нужно переопределить некоторые атрибуты, наследуемые от GenericAPIView, то есть задать значения для queryset и serializer_class. Остальные атрибуты можно увидеть здесь.

Откройте project/api/views.py и внесите следующие изменения:

from django.contrib.auth.models import User
from rest_framework import viewsets
from project.api.serializers import UserSerializer
class UserViewSet(viewsets.ModelViewSet):
    """
    Конечная точка API, позволяющая просматривать или редактировать пользователей.
    """
    queryset = User.objects.all()
    serializer_class = UserSerializer

В приведенном выше фрагменте кода мы:

импортировали модель User, библиотеку viewsets и наш новый UserSerializer
создали представление UserViewSet, которое наследуется от ModelViewSet
переопределили атрибуты queryset и serializer_class класса ModelViewSet

Существует множество других атрибутов и функций, которые мы можем переопределить в ModelViewSet, однако queryset и serializer_class нужно изменить обязательно, чтобы они соответствовали модели User:

queryset - это запрос к базе данных, который вернет все объекты для метода .list()
serializer_class - это класс-сериализатор, который используется для функций.

9. URL-адреса и DRF маршрутизаторы

Теперь, когда готовы сериализатор и представления для нашей модели User, настало время написать маршрутизатор, который автоматически создаст URL-адреса вместо нас из ViewSet!

У маршрутизаторов есть два атрибута, которые нужно обязательно настроить: prefix и viewset. Третий атрибут - base_name - можно настроить позже. prefix - это регулярное выражение, с которого будут начинаться наши URL-адреса. Мы добавим маршрутизатор для модели User в файл api/urls.py, как показано ниже:

from django.conf.urls import url, include
from rest_framework import routers
from project.api import views
router = routers.DefaultRouter()
router.register(r'users', views.UserViewSet)
urlpatterns = [
    url(r'^', include(router.urls)),
]

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

10. Тестируем Ваше API!

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

# Команда
python manage.py runserver

После того как сервер стартовал, мы можем просмотреть API Root в браузере! Перейдите по адресу http://localhost:8000/ и Вы должны увидеть эту страницу!

API Root, отображающий пользователей

Вы можете щелкнуть по ссылке http://localhost:8000/users/, чтобы получить список пользователей. Нажав на ссылку конкретного пользователя отобразится информация о нём. Графический интерфейс позволяет Вам создавать, удалять или обновлять значения модели User или любой другой. Этими же возможностями можно воспользоваться через терминал с помощью инструментов таких как curl.

Используя curl, мы можем осуществить GET запрос по адресу /users/ и получить данные в JSON формате в терминале:

curl -H 'Accept: application/json; indent=4' http://localhost:8000/users/

Когда осуществляется запрос по адресу /users/ в терминале или браузере происходит следующее: выполняется HTTP запрос с методом GET запрашивающий ресурс, расположенный по адресу /users/. Маршрутизатор отправляет этот запрос в UserViewSet, который обрабатывает его и определяет, что должен вернуть список всех пользователей.

Если послать POST запрос с определенным набором данных на тот же URL-адрес, то это приведет к созданию нового пользователя!

Выводы

В этом разделе было рассмотрено большое количество информации, включая понятия HTTP, REST и Django приложений. Затем мы показали как Django REST фреймворк использует рассмотренные HTTP понятия в связке с URL-адресами и представлениями.

Этот проект со всеми разделами можно найти на GitHub по этой ссылке.

Как всегда отзывы, советы, приёмы и критика приветствуются в комментариях или по электронной почте.

С наилучшими пожеланиями и спасибо,

Дилан Штейн.

Благодарю Карла Хилтбруннера (Carl Hiltbrunner).

Часть 2: REST API, приложения и Django REST фреймворк

Часть 2: REST API, приложения и Django REST фреймворк

Введение

Используемые технологии

Подробное пошаговое руководство

1. Краткий курс по HTTP и REST

1-A. Принцип работы Интернета, используя уровни модели OSI

1-B. URLы и ресурсы

1-C. HTTP запросы и ответы

1.4 HTTP методы

1.5 Коды состояния

1.6 RESTful API

1.7 Резюме

2. Введение в Django приложения

3. Введение в Django REST фреймворк

4. Добавление приложений, предназначенных не для настройки проекта

6. Устанавливаем и настраиваем Django REST фреймворк

6-1. Устанавливаем Django REST фреймворк

6-2. Настраиваем Django REST фреймворк

7. Сериализаторы

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

8-1. Представления

8-2. Представления-классы

8-3. Обобщенные представления и ViewSetы Django REST фреймворка

8-4. Создаём ViewSet для нашей модели User

9. URL-адреса и DRF маршрутизаторы

10. Тестируем Ваше API!

Выводы

results matching ""

No results matching ""