Запрос DRF - это то, что вы отправляете на сервер для установления первого или последующего контакта. Думайте о запросе как о том, как вы представитесь серверу.

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

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

Читая комнату

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

Это одна из квалификаций, которая заставит вас либо продолжить запрос, либо вернуться и вернуться с лучшим вариантом. Так что это часть основ DRF-запросов.

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

Правильные ли данные предоставил пользователь? Могут ли доступные средства визуализации обрабатывать предоставленные данные запроса? Что ж, если все в порядке, то пора выходить на контакт.

Установить контакт

Итак, следующее - установить контакт, и здесь вы сможете предъявить свою претензию владельцу магазина. В этой части этого руководства по запросам DRF мы и собираемся взглянуть на это.

Первый сценарий - когда вы новичок в этом месте или на этот раз вы найдете другого продавца? Что ж, должно быть какое-то доверие, которое нужно установить, прежде чем что-то может продолжаться, не так ли? Благодаря этому у нас есть аутентификация.

Вам нужно будет убедить продавца в том, что «эй, возможно, мы не встречались раньше, НО я проверяю как надежный человек». Таким образом, в зависимости от требуемых деталей, владелец магазина решит, согласиться и продать вам или отказаться от своей услуги, поскольку они не уверены, что вы являетесь тем, кем вы себя называете, поскольку он / она не хочет иметь проблем с властями. Однако, если вы выезжаете из магазина, все в порядке, и продавец может продолжить продажу вам.

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

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

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

Он будет получен от request.user, который вернет либо аутентифицированного пользователя, либо AnonymousUser. Кроме того, это будет зависеть от используемой схемы аутентификации платформы Django REST.

Это можно сделать глобально с помощью REST_FRAMEWORK.DEFAULT_AUTHENTICATION_CLASSES или для каждого представления с помощью декоратора @authentication_classes. Это список из нескольких существующих схем аутентификации:

  • Базовая проверка подлинности
  • SessionAuthentication
  • ТокенАутентификация

Более того, если есть опция аутентификации на основе токена, то request.auth предоставит контекст аутентификации и также предоставит токен. Таким образом, этот токен похож на «память», которую владелец магазина (сервер) использует для запоминания каждого из своих клиентов (клиентов).

Итак, теперь, когда между вами установилось достаточно доверия, кажется, что пришло время совершить покупку.

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

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

Вы заинтересованы в изучении Django REST Framework? Посмотрите похожие классные статьи на моем сайте: Binge On Code› Django Rest Framework