DRF

Question 1

API

Answer 1

API (от англ. Application Programming Interface, «программный интерфейс приложения») — это интерфейс для обмена данными. Слово «программный» означает, что API служат в первую очередь для взаимодействия программ: с системой взаимодействует не разработчик, а код, написанный им.

Question 2

JSON

Answer 2

Текстовый формат обмена данными, основанный на JavaScript. JavaScript Object Notation (англ. «объектная запись JavaScript»). Исторически сложилось так, что этот формат «вырос» из языка программирования JavaScript. По структуре JSON очень похож на тип данных dict: это последовательность пар «ключ-значение»; как и словари, JSON поддерживает вложенность. Но JSON более стандартизирован: например, ключи словаря в JSON пишутся только в двойных кавычках. Значениями ключей могут быть строки, числа, булевы значения, словари и списки.

Question 3

XML

Answer 3

JSON — популярный, но не единственный формат для передачи данных.
XML (eXtensible Markup Language, «расширяемый язык разметки») тоже весьма популярен и широко применяется в разработке. Внешне этот язык чем-то похож на HTML, и это неслучайно: язык разметки веб-страниц — прямой потомок XML.

Question 4

Архитектура REST

Answer 4

REST (англ. REpresentational State Transfer, «передача состояния представления») — это архитектурный стиль, набор принципов взаимодействия компьютерных систем, основанный на методах протокола HTTP. В отличие от SOAP, REST не подкреплен официальным стандартом.

Question 5

REST

Answer 5

REpresentational State Transfer, REST (англ. «передача состояния представления») — это набор принципов, которых следует придерживаться при создании API. Если API сделан по этим принципам, его называют RESTful API (или просто REST API).

Question 6

Принципы REST #1

Answer 6

1. Клиент-сервер. Разделение ответственности между клиентом и сервером
   Клиент и сервер отвечают за разные вещи. Ответственность клиента — пользовательский интерфейс, ответственность сервера — данные. Если API возвращает HTML-страницу, его нельзя назвать REST API: ведь при этом сервер берёт на себя ответственность за интерфейс.

Question 7

Принципы REST #2

Answer 7

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

Question 8

Принципы REST #3

Answer 8

3. Единый интерфейс
   Интерфейс обращения к серверу одинаков для всех и не зависит от клиента. Запрос к данным может быть сформирован из браузера, мобильного приложения и с «умного» чайника по одним и тем же правилам.

Question 9

Принципы REST #4

Answer 9

4. Многоуровневость
   Первый принцип гласит, что в коммуникации участвуют двое: клиент и сервер. Но можно строить более сложные системы, не нарушая этого принципа.
   API сервиса Яндекс.Такси может использовать API Яндекс.Навигатора. Вы как клиент взаимодействуете только с API Яндекс.Такси, а он, в свою очередь, является клиентом навигатора. Здесь есть одно условие — каждый компонент должен видеть только свой уровень. Например, Яндекс.Навигатор не должен видеть все данные, которые вы отправили в Яндекс.Такси.

Question 10

Принципы REST #5

Answer 10

5. Кешируемость
   Данные ответа могут быть закешированы. Это значит, что можно сохранить полученные данные на клиенте, а при идентичном запросе взять их из памяти клиента — кеша, а не ждать их с сервера. Нет смысла запрашивать данные повторно, если они никак не изменились.

Question 11

Принципы REST #6

Answer 11

6. Код по запросу
   Этот принцип необязательный. Он гласит, что функциональность клиента может быть расширена кодом, приходящим с сервера. Сейчас такое можно встретить повсеместно: JavaScript используется для «оживления» страниц и исполнения каких-то сценариев на стороне клиента. Но принципы формулировались в 2000 году — тогда исполняемый код с сервера возвращали не так часто. Потому и выделили это в отдельный принцип.

Question 12

Ключевая абстракция в REST

Answer 12

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

Question 13

эндпоинт

Answer 13

В терминах REST URL-адрес, идентифицирующий ресурс, принято называть эндпоинтом (англ. endpoint, «конечная точка»).

Question 14

HTTP-методы

Answer 14

Любой API предназначен для получения доступа к ресурсам. К ресурсу всегда можно обратиться по URL.
HTTP-метод запроса определяет, что следует сделать:

GET получает ресурсы;
POST создаёт ресурс;
PUT заменяет существующий ресурс целиком;
PATCH частично изменяет существующий ресурс;
DELETE удаляет ресурс.

Question 15

Идемпотентность методов

Answer 15

Идемпотентность (от лат. idem — «тот же самый» и potens — «способный») — это свойство, заключающееся в том, что многократное выполнение этого метода по результату равно однократному. То есть, выполняя один и тот же запрос много-много раз, мы всегда будем получать один и тот же результат. Даже если сто раз отправить GET-запрос на получение никнейма конкретного пользователя, ответ не изменится

Question 16

Безопасность методов

Answer 16

Безопасность: метод, который не изменяет ресурс, называется безопасным. Например, если в качестве ресурса рассматривать никнеймы пользователей, то сколько ни отправляй GET-запрос на получение никнейма конкретного пользователя — к изменению никнейма это не приведёт. Метод GET — безопасный.
Метод, который может изменить ресурс, в терминах архитектуры REST считается небезопасным. Такими методами могут быть PUT, PATCH, DELETE или POST.

Question 17

Авторизация

Answer 17

Авторизация (англ. authorization, «разрешение, одобрение») — предоставление пользователю прав на выполнение каких-то действий

Question 18

Аутентификация

Answer 18

Аутентификация (англ. authentication, «опознание») — процедура проверки подлинности пользователя

Question 19

OAuth (Open Authorization)

Answer 19

OAuth (Open Authorization) — это схема авторизации, предоставляющая третьей стороне (другому пользователю или приложению) ограниченный доступ к ресурсам сервиса от вашего имени, без необходимости передавать логин и пароль. Это становится возможным благодаря OAuth-токену.

Question 20

Токен

Answer 20

Токен (англ. “token” – опознавательный знак, жетон) — это уникальная строка из цифр и латинских букв, он может выглядеть так:
854234bfefcf1f000d92df5e4c5e8858b9ebcb4821e12cd806add07e17f587c4c93e3b50d5adbdae2b2

Question 21

Django REST Framework

Answer 21

Это библиотека которая ускорит и упростит разработку REST API.
Django REST Framework (DRF) предоставляет разработчику весь необходимый набор инструментов для создания REST-сервисов на основе Django. По сути, DRF — это коллекция предустановленных классов. DRF даёт инструменты для решения штатных задач, возникающих при создании REST API.

Question 22

Принцип проектирования API - Консистентность

Answer 22

Консистентность — это согласованность данных друг с другом, их целостность и внутренняя непротиворечивость. Например, данные о каком-то объекте, полученные с одного эндпоинта, не должны отличаться от данных о том же объекте, но полученных с другого эндпоинта.
Пример с полем date и его форматом для энда пост и для энда коммент

Question 23

Принцип проектирования API - Согласованность

Answer 23

Понятие консистентности включает в себя и идею согласованности: добавление в API новой функциональности не должно сломать API.

Question 24

Принцип проектирования API - Расширяемость

Answer 24

Пример с отдачей данных не в виде упорядоченного списка: [[1, “Это мой первый комментарий.”, 1618565516, 10]] Так иногда делают для повышения производительности, но в нашей ситуации этот вариант оказался непрактичен: он усложняет расширяемость. Здесь лучше отдавать данные в более распространённом для JSON формате, аналогичном словарю, со структурой {“ключ”: “значение”}.
При такой структуре добавление новых элементов не повлечёт за собой проблем с парсингом данных. Клиенты будут получать необходимую информацию из ответа по прежним ключам, а новые ключи могут использовать, а могут игнорировать. И ничего не сломается.

Question 25

Инструментарий для тестирования API

Answer 25

Такие программы можно условно разделить на консольные (такие как curl и httpie), встраиваемые (плагины для браузера или для редактора кода, например, REST Client для VS Code) и графические (Postman).

Question 26

Сериализаторы - что такое?

Answer 26

Сериализаторы преобразуют сложные данные, такие как queryset или экземпляр модели, в простые типы данных Python, которые затем можно конвертировать («отрендерить») в JSON, XML или другие форматы обмена.

Сериализаторы выполняют и обратное преобразование: конвертируют данные, полученные из JSON, в сложные объекты; при этом данные проходят валидацию.

Question 27

class Serializer

Answer 27

Для работы с обычными Python-классами сериализаторы наследуют от класса Serializer.

Question 28

SerializerMethodField

Answer 28

~~~

```SerializerMethodField — это поле для чтения, связанное с определённым методом, в котором будет вычислено значение этого поля. Метод, который будет вызван для поля <имя_поля>, по умолчанию должен называться get_<имя_поля>.</имя_поля></имя_поля>

С помощью поля SerializerMethodField можно модифицировать существующее поле или создать новое.
Добавьте в сериализатор CatSerializer поле age (его нет в модели Cat); содержимое этого поля будет вычисляться «на лету» в методе get_age:
…
import datetime as dt
…

class CatSerializer(serializers.ModelSerializer):
achievements = AchievementSerializer(many=True)
age = serializers.SerializerMethodField()

class Meta:
    model = Cat
    fields = ('id', 'name', 'color', 'birth_year', 'owner', 'achievements',
              'age')

def get_age(self, obj):
    return dt.datetime.now().year - obj.birth_year

Question 29

Обработка запросов к API

Answer 29

Для обработки запросов к API могут использоваться представления как в виде функций, так и в виде классов. Функции, как правило, позволяют лучше понять как работает код; вот с них и начнём.
1. View-функции API
2. View-классы API
3. Viewset

Question 30

View-функции API

Answer 30

Для «настройки» view-функции на работу с API в Django REST framework есть декоратор @api_view. В качестве аргумента декоратору передают список типов HTTP-запросов, которые должна обрабатывать эта функция:
~~~
api_view([‘GET’, ‘POST’]) # Разрешены только POST- и GET-запросы
def cat_list(request):
# В случае POST-запроса добавим список записей в БД
if request.method == ‘POST’:
serializer = CatSerializer(data=request.data, many=True)
if serializer.is_valid():
serializer.save()
return Response(serializer.data, status=status.HTTP_201_CREATED)
return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
# В случае GET-запроса возвращаем список всех котиков
cats = Cat.objects.all()
serializer = CatSerializer(cats, many=True)
return Response(serializer.data)
~~~

Question 31

Отличие view-функции API в Django REST framework состоит в том…..

Answer 31

…что они возвращают специальный объект класса Response; в этот объект в качестве аргумента передаётся Python-словарь, данные из которого и должны быть отправлены в ответ на запрос в JSON формате.

Question 32

Данные в запросе приходят в формате JSON….

Answer 32

….преобразуются в Python-словарь, доступ к которому можно получить через объект request.data. Этот словарь и передаётся в сериализатор через именованный параметр data.
~~~
@api_view([‘GET’, ‘POST’])
def cat_list(request):
# Обработчик для POST-запросов.
if request.method == ‘POST’:
serializer = CatSerializer(data=request.data)
~~~

Question 33

View-классы API (как следующий этап работы с Views в DRF после view-функций)

Answer 33

Встроенные классы DRF можно условно разделить на низкоуровневые и высокоуровневые. Низкоуровневые содержат лишь базовую структуру класса, его скелет; разработчик сам должен описать работу класса; их применяют для решения нестандартных задач.
Типовые задачи (скажем, CRUD) удобнее решать с помощью высокоуровневых view-классов: в них уже заготовлены все инструменты для решения стандартных задач.

Question 34

Низкоуровневые view-классы в DRF - APIView

Answer 34

view-класс APIView импортируется из модуля rest_framework.views
~~~
class MyAPIView(APIView):
def get(self, request):
…

def post(self, request):
    ...

def put(self, request):
    ...

def patch(self, request):
    ...

def delete(self, request):
    ...  ~~~

Question 35

Generic Views: высокоуровневые view-классы

Answer 35

В дженериках задают всего два поля: queryset (набор записей, который будет обрабатываться в классе) и serializer_class (сериализатор, который будет преобразовывать объекты в формат JSON). В DRF все Generic Views объединены в модуле rest_framework.generics.

# Обновлённый views.py
from rest_framework import generics

from .models import Cat
from .serializers import CatSerializer

class CatList(generics.ListCreateAPIView):
    queryset = Cat.objects.all()
    serializer_class = CatSerializer

class CatDetail(generics.RetrieveUpdateDestroyAPIView):
    queryset = Cat.objects.all()
    serializer_class = CatSerializer

Question 36

Generic Views все классы

Answer 36

GENERICS
CreateAPIView
DestroyAPIView
GenericAPIView
ListAPIView
ListCreateAPIView
RetrieveAPIView
RetrieveDestroyAPIView
RetrieveUpdateAPIView
RetrieveUpdateDestroyAPIView
UpdateAPIView

Question 37

Viewset: после view-функций и view-классов

Answer 37

Вьюсет (англ. viewset, «набор представлений») — это высокоуровневый view-класс, реализующий все операции CRUD; он может вернуть объект или список объектов, создать, изменить или удалить объекты.

они хранятся в пакете rest_framework.viewsets

Question 38

Viewset - ModelViewSet

Answer 38

Класс ModelViewSet может выполнять любые операции CRUD с моделью. От разработчика не требуется описывать методы для чтения и записи данных для модели: эти операции уже реализованы.
В классе, наследующемся от ModelViewSet, обязательно должны быть описаны два поля:
1. в поле queryset задаётся выборка объектов модели, с которой будет работать вьюсет;
2. в поле serializer_class указывается, какой сериализатор будет применён для валидации и сериализации.

from rest_framework import viewsets 

from .models import Cat
from .serializers import CatSerializer

class CatViewSet(viewsets.ModelViewSet):
    queryset = Cat.objects.all()
    serializer_class = CatSerializer 

Question 39

Viewset - ReadOnlyModelViewSet

Answer 39

В пакете rest_framework.viewsets есть похожий на ModelViewSet, но ограниченный в правах класс ReadOnlyModelViewSet. Он может только получать данные модели, а записывать и изменять — не может.
Этот класс полезен в ситуациях, когда требуется только выдавать данные по запросу, без возможности их изменить. В остальном ReadOnlyModelViewSet работает точно так же, как и ModelViewSet.

Question 40

Роутеры

Answer 40

С помощью роутера для заданных вьюсетов создаются эндпоинты по маске адреса:
~~~
URL-префикс/
URL-префикс/<int:pk>.
~~~
В DRF есть два стандартных роутера: SimpleRouter и DefaultRouter.</int:pk>

Question 41

SimpleRouter

Answer 41

urls.py

В файл urls.py импортируйте класс SimpleRouter и создайте экземпляр этого класса.
~~~
from rest_framework.routers import SimpleRouter

router = SimpleRouter()
~~~
router.register('cats', CatViewSet)
После регистрации надо включить новые эндпоинты в список urlpatterns: перечень эндпоинтов будет доступен в router.urls.

Question 42

DefaultRouter

Answer 42

DefaultRouter — это расширенная версия SimpleRouter: он умеет всё то же, что и SimpleRouter, а в дополнение ко всему генерирует корневой эндпоинт /, GET-запрос к которому вернёт список ссылок на все ресурсы, доcтупные в API.