request и response что это
Описание, атрибуты и методы объекта requests.Response.
Синтаксис:
Параметры:
Описание:
Объект requests.Response модуля requests содержит всю информацию ответа сервера на HTTP-запрос requests.get(), requests.post() и т.д.
Объект ответа сервера requests.Response генерируется после того, как библиотека requests получают ответ от сервера. Объект ответа Response содержит всю информацию, возвращаемую сервером, а также объект запроса, который создали изначально.
Response.apparent_encoding :
Response.close() :
Метод Response.close() освобождает соединение с пулом. Как только этот метод был вызван, базовый необработанный объект больше не будет доступен.
Примечание: обычно не нужно вызывать явно.
Response.content :
Атрибут Response.content возвращает содержание ответа сервера, представленное в байтах.
Response.cookies = None :
Атрибут Response.cookies возвращает хранилище CookieJar файлов cookie, которые сервер отправил обратно.
Response.elapsed = None :
Атрибут Response.elapsed возвращает время, прошедшее между отправкой запроса и получением ответа (в виде timedelta ).
Response.encoding = None :
Response.headers = None :
Атрибут Response.headers возвращает словарь без учета регистра, с заголовками сервера, которые он вернул во время ответа.
Response.history = None :
Атрибут Response.history возвращает список объектов ответа сервера из истории запроса. Здесь окажутся все перенаправленные ответы.
Список сортируется от самого старого до самого последнего запроса.
Response.is_permanent_redirect :
Response.is_redirect :
Атрибут Response.is_redirect возвращает True если этот ответ является хорошо сформированным HTTP-перенаправлением, которое могло бы быть обработано автоматически ( Session.resolve_redirects ).
Response.iter_content(chunk_size=1, decode_unicode=False) :
Response.iter_lines(chunk_size=512, decode_unicode=False, delimiter=None) :
Обратите внимание, что этот метод не является безопасным для повторного входа.
Response.json(**kwargs) :
Метод Response.json() возвращает закодированное в json содержимое ответа, если таковое имеется.
Response.links :
Атрибут Response.links возвращает проанализированные ссылки заголовка ответа, если таковые имеются.
Response.next :
Атрибут Response.next возвращает объект подготовленного запроса PreparedRequest для следующего запроса в цепочке перенаправления, если таковой имеется.
Response.ok :
Стандарт PSR7 — Веб-разработка на PHP
Архитектура любого серверного веб-фреймворка, опирается на особенности протокола HTTP. В первую очередь сюда входят понятия запроса (request) и ответа (response). Это значит что каждому веб-фреймворку, так или иначе, приходится реализовывать эти объекты у себя, повторяя то, что уже было сделано в других местах.
Чтобы избежать такой ситуации, был разработан стандарт PSR7. Цель PSR-7 предоставить общий набор интерфейсов для фреймворков, чтобы последние могли использовать одинаковые абстракции. Это позволит разработчикам писать переиспользуемый, независимый от фреймворка код. Сам стандарт довольно объёмный и не имеет смысла его дублировать. Здесь мы поговорим только о ключевых особенностях.
Request и Response, с точки зрения стандарта, представляют собой абстракцию поверх механизмов встроенных в сам PHP. Например, они полностью заменяют собой суперглобальные массивы, механизм загрузки файлов и многое другое.
Объекты запроса и ответа во фреймворке Slim имеют интерфейс соответствующий стандарту PSR-7. Пример на главной странице фреймворка как раз демонстрирует это:
getBody() возвращает специальный объект-поток (stream). Этот объект можно изменять, записывая туда данные.
Интерфейсы, описанные в PSR7, эмулируют работу HTTP. С помощью их методов можно как извлечь любую информацию из запроса, так и создать любой ответ.
Эти методы работают не только для запроса, но и для ответа. Дело в том, что оба эти интерфейса Request и Response, имеют общую часть, которая называется Message, другими словами, многие методы повторяются и одинаково работают в каждом из этих объектов.
Response
Ответ аккумулирует внутри себя то, что отправится клиенту, но он изначально не пустой, а содержит некоторые разумные умолчания:
А вот с изменением все не так просто. Главная отличительная черта этого интерфейса в том, что он построен в иммутабельном (неизменяемом) стиле и реализует текучий интерфейс (fluent interface). Ответ невозможно «изменить» (ниже будет одно исключение). Вместо этого, всегда возвращается новый объект.
По этой причине, во фреймворках, поддерживающих стандарт PSR-7, обработчик запроса всегда должен вернуть объект ответа, только в этом случае фреймворк узнает о том, как надо ответить на запрос.
Единственная часть в Response, которую можно менять – тело ответа. Это связано с техническими особенностями работы потоков в самом PHP. Подробнее об этом можно прочитать в документации
Несмотря на все это, PSR7 достаточно низкоуровневый стандарт. Он не ставил перед собой целью сделать работу с объектами ответа и запроса максимально удобной и простой. Задача была в эмуляции поведения HTTP. Поэтому помимо реализации стандартных интерфейсов, многие фреймворки создают дополнительные обертки поверх PSR7. Эти обертки уже дают много прикладных полезных методов. Одну из таких оберток мы начали использовать с самого начала: Slim-Http. Вот лишь небольшой список полезных функций этой библиотеки которые мы либо использовали, либо будем использовать:
Открыть доступ
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.
Объекты запроса и ответа (Request & Response Objects)
Содержание
Объекты запроса и ответа (Request & Response Objects) являются абстрактными представителями HTTP-запросов и ответов. Объект запроса в CakePHP позволяет работать с входящим запросом, в то время как объект ответа позволяет легко создавать ответы HTTP от контроллеров приложения.
Запрос (Request)
class Cake\Http\ServerRequest
Начиная с версии 3.4.0, объект запроса CakePHP реализует PSR-7 ServerRequestInterface, что упрощает использование библиотек вне CakePHP.
Параметры запроса
Параметры маршрутизации из объекта запроса можно получить используя метод getParam():
Через этот интерфейс доступны все элементы маршрута.
Помимо Route Elements (элементов маршрута),также часто необходим доступ к Passed Arguments (передаваемым аргументам). Они также доступны в объекте запроса:
Всё это предоставят доступ к переданным аргументам. Существует несколько важных/полезных параметров, которые CakePHP использует внутренне, все они также находятся в параметрах маршрутизации:
Параметры строки запроса
Cake\Http\ServerRequest::getQuery($name)
Параметры строки запроса можно прочитать с помощью метода getQuery():
Вы можете либо напрямую получить доступ к свойству запроса, указав имя свойства, либо использовать метод getQuery() без указания имени (ключа) для чтения всего массива запроса. Любые ключи, которые не существуют, будут приводить к возвращению значения null:
Так же, для получения доступа ко всем параметрам запроса, можно использовать getQueryParams ():
Новое в версии 3.4.0: getQueryParams() и getQuery() добавлены в 3.4.0
Данные тела запроса
Доступ ко всем данным POST можно получить с помощью Cake\Http\ServerRequest::getData(). Любые данные, отправленные из формы, содержащие многомерный массив, будут иметь префикс данных. Например:
Любые ключи, которые не существуют, будут возвращать значение null:
Данные методов PUT, PATCH или DELETE в запросе
При создании REST сервиса часто бывает необходимо принимать в запросе данные PUT и DELETE. Любые application/x-www-form-urlencoded данные тела запроса автоматически анализируются, парсятся и заносятся в $this->data для запросов PUT и DELETE. Если вы принимаете данные JSON или XML, то ниже показано, как можно получить доступ к телам этих запросов.
Для доступа к входным данным вы можете декодировать их с помощью дополнительной функции. Это полезно при взаимодействии с содержимым тела запроса XML или JSON. Дополнительные параметры для функции декодирования могут передаваться в качестве аргументов для input():
Чтобы получить доступ ко всем переменным среды в запросе, используется getServerParams():
Новое в версии 3.4.0: Метод getServerParams() добавлен в 3.4.0
XML или JSON данные
Приложения, использующие REST, часто обмениваются данными без URL-кодирования. Прочитать входные данные любого формата, можно используя Http\\ServerRequest::input(). Указывая функцию декодирования, вы можете получать контент в десериализованном формате:
Некоторые методы десериализации требуют дополнительных параметров при вызове, таких как параметр «ассоциативный массив» при использовании json_decode. Если вы хотите преобразовать XML в объект DOMDocument, Http\ServerRequest::input() поддерживает передачу дополнительных параметров:
Информация о пути (Path)
Объект запроса также предоставляет информацию о путях в вашем приложении. Атрибуты base и webroot полезны для создания URL-адресов и определения того, находится ли ваше приложение в подкаталоге. Возможно использование следующих атрибутов:
Проверка условий запроса
Объект запроса обеспечивает простой способ проверки определенных условий в запросе. Используя метод is(), можно проверить ряд общих условий, а также другие критерии запроса конкретного приложения:
Так же, можно расширить условия проверки запросов, используя Cake\Http\ServerRequest::addDetector() для создания новых типов детекторов. Существует четыре разных типа детекторов, которые могут быть созданы:
Вот некоторые примеры:
Request также включает в себя такие методы, как: Cake\Http\ServerRequest::domain(), Cake\Http\ServerRequest::subdomains() и Cake\Http\ServerRequest::host(), чтобы помочь облегчить жизнь при создании приложений с субдоменами.
Существует несколько встроенных детекторов, которые вы можете использовать:
Новое в версии 3.3.0: Детекторы могут принимать дополнительные параметры начиная с версии 3.3.0
Данные сессии (Session Data)
Для доступа к сессии текущего запроса используется метод session():
Хост и доменное имя
Cake\Http\ServerRequest::domain($tldLength = 1)
Возвращает имя домена, в котором работает ваше приложение:
Cake\Http\ServerRequest::subdomains($tldLength = 1)
Возвращает субдомены, в которых работает ваше приложение, в виде массива:
Cake\Http\ServerRequest::host()
Возвращает хост, на котором установлено ваше приложение:
Чтение HTTP-метода
Cake\Http\ServerRequest::getMethod()
Возвращает метод HTTP, на основе которого был выполнен запрос:
Ограничение того, какой метод HTTP может принимать экшен
Cake\Http\ServerRequest::allowMethod($methods)
После установки допустимых методов HTTP, если они не будут согласованы с запросом, выбросится исключение MethodNotAllowedException. Ответ 405 будет включать заголовок с указанием разрешенных методов:
Чтение заголовков HTTP
Позволяет получить доступ к любому из заголовков HTTP_ *, которые были использованы для запроса. Например:
Хотя некоторые установки Apache делают заголовок при авторизации не доступным, CakePHP сделает его доступным по специальным методам apache в случае необходимости.
Cake\Http\ServerRequest::referer($local = false)
Возвращает URL адрес источника запроса.
Cake\Http\ServerRequest::clientIp()
Возвращает IP-адрес текущего посетителя.
Заголовки доверенного прокси
Если ваше приложение находится за балансировщиком нагрузки или работает в облачном сервисе, часто бывает необходимо получать от них хост, порт и схему в своих запросах. Такие балансировки нагрузки также отправляют заголовки HTTP-X-Forwarded- * с исходными значениями. Пересылаемые заголовки не будут использоваться CakePHP из коробки. Чтобы объект запроса использовал эти заголовки, для свойства trustProxy необходимо установить значение true:
Проверка принимающих заголовков
Cake\Http\ServerRequest::accepts($type = null)
Можно узнать, какие типы данных (Content-Type) принимает клиент, или проверьте, принимает ли он конкретный Content-Type.
Проверка конкретного типа:
Cake\Http\ServerRequest::acceptLanguage($language = null)
Получить все языки, принятые клиентом, или проверить, принят ли конкретный язык.
Получить список принятых языков::
Проверьте, принят ли конкретный язык::
Cookie (куки)
Куки запроса можно прочитать несколькими способами:
См. документацию по Cake\Http\Cookie\CookieCollection для работы с экземпляром коллекции файлов куки.
Новое в версии 3.5.0: ServerRequest::getCookieCollection() добавлен в версии 3.5.0
Ответ (Response)
class Cake\Http\Response
Response предоставляет интерфейс для объединения задач, связанных с ответом, таких как:
Работа с типами контента
Cake\Http\Response::withType($contentType = null)
Вы можете управлять Content-Type в ответах приложения с помощью Cake\Http\Response::withType(). Если приложению нужно иметь дело с Content-Types, которые не встроены в Response, их можно также сопоставить с type():
Обычно необходимо отображать дополнительные Content-Type в обратном вызове beforeFilter() контроллера, для этого можно использовать функции автоматического переключения вида RequestHandlerComponent, при его использовании.
Отправка файлов
Бывают случаи, когда необходимо отправлять файлы в качестве ответов на запросы. Это можно делать, используя Cake\Http\Response::withFile():
Как показано в приведённом выше примере, необходимо в метод передать путь к файлу. CakePHP отправит соответствующий заголовок типа контента, если это известный тип файла, указанный в Cake\Http\Reponse::$_mimeTypes. Вы можете добавлять новые типы до вызова Cake\Http\Response::withFile() с помощью метода Cake\Http\Response::withType().
Также можно принудительно загрузить файл вместо отображения страницы в браузере, указав параметры:
Отправка строки в виде файла
Так же, можно ответить файлом, который не существует на диске, например, pdf или ics, сгенерированным «на лету» из строки:
Обратные вызовы также могут возвращать тело в виде строки:
Настройка заголовков
Настройка заголовков выполняется с помощью метода Cake\Http\Response::withHeader(). Как и все методы интерфейса PSR-7, этот метод возвращает экземпляр new с новым заголовком:
Заголовки не отправляются при установке. Вместо этого они сохраняются до тех пор, пока не будет получен ответ Cake\Http\Server.
Теперь вы можете использовать удобный метод Cake\Http\Response::withLocation(), чтобы напрямую установить или получить заголовок местоположения перенаправления.
Настройка body
Cake\Http\Response::withStringBody($string)
Чтобы установить строку в качестве тела ответа, необходимо выполнить следующие действия:
Типы HTTP-запросов и философия REST
Этот пост — ответ на вопрос, заданный в комментарии к одной из моих статей.
В статье я хочу рассказать, что же из себя представляют HTTP-методы GET/POST/PUT/DELETE и другие, для чего они были придуманы и как их использовать в соответствии с REST.
Итак, что же представляет из себя один из основных протоколов интернета? Педантов отправлю к RFC2616, а остальным расскажу по-человечески 🙂
Этот протокол описывает взаимодействие между двумя компьютерами (клиентом и сервером), построенное на базе сообщений, называемых запрос (Request) и ответ (Response). Каждое сообщение состоит из трех частей: стартовая строка, заголовки и тело. При этом обязательной является только стартовая строка.
Стартовые строки для запроса и ответа имеют различный формат — нам интересна только стартовая строка запроса, которая выглядит так:
где METHOD — это как раз метод HTTP-запроса, URI — идентификатор ресурса, VERSION — версия протокола (на данный момент актуальна версия 1.1).
Заголовки — это набор пар имя-значение, разделенных двоеточием. В заголовках передается различная служебная информация: кодировка сообщения, название и версия браузера, адрес, с которого пришел клиент (Referrer) и так далее.
Тело сообщения — это, собственно, передаваемые данные. В ответе передаваемыми данными, как правило, является html-страница, которую запросил браузер, а в запросе, например, в теле сообщения передается содержимое файлов, загружаемых на сервер. Но как правило, тело сообщения в запросе вообще отсутствует.
Пример HTTP-взаимодействия
Первая строка — это строка запроса, остальные — заголовки; тело сообщения отсутствует
Ресурсы и методы
Вернемся к стартовой строке запроса и вспомним, что в ней присутствует такой параметр, как URI. Это расшифровывается, как Uniform Resource Identifier — единообразный идентификатор ресурса. Ресурс — это, как правило, файл на сервере (пример URI в данном случае ‘/styles.css’), но вообще ресурсом может являться и какой-либо абстрактный объект (‘/blogs/webdev/’ — указывает на блок «Веб-разработка», а не на конкретный файл).
Тип HTTP-запроса (также называемый HTTP-метод) указывает серверу на то, какое действие мы хотим произвести с ресурсом. Изначально (в начале 90-х) предполагалось, что клиент может хотеть от ресурса только одно — получить его, однако сейчас по протоколу HTTP можно создавать посты, редактировать профиль, удалять сообщения и многое другое. И эти действия сложно объединить термином «получение».
В игру вступает REST
REST (REpresentational State Transfer) — это термин был введен в 2000-м году Роем Филдингом (Roy Fielding) — одним из разработчиков протокола HTTP — в качестве названия группы принципов построения веб-приложений. Вообще REST охватывает более широкую область, нежели HTTP — его можно применять и в других сетях с другими протоколами. REST описывает принципы взаимодействия клиента и сервера, основанные на понятиях «ресурса» и «глагола» (можно понимать их как подлежащее и сказуемое). В случае HTTP ресурс определяется своим URI, а глагол — это HTTP-метод.
REST предлагает отказаться от использования одинаковых URI для разных ресурсов (то есть адреса двух разных статей вроде /index.php?article_id=10 и /index.php?article_id=20 — это не REST-way) и использовать разные HTTP-методы для разных действий. То есть веб-приложение, написанное с использованием REST подхода будет удалять ресурс при обращении к нему с HTTP-методом DELETE (разумеется, это не значит, что надо давать возможность удалить всё и вся, но любой запрос на удаление в приложении должен использовать HTTP-метод DELETE).
REST дает программистам возможность писать стандартизованные и чуть более красивые веб-приложения, чем раньше. Используя REST, URI для добавления нового юзера будет не /user.php?action=create (метод GET/POST), а просто /user.php (метод строго POST).
В итоге, совместив имеющуюся спецификацию HTTP и REST-подход наконец-то обретают смысл различные HTTP-методы. GET — возвращает ресурс, POST — создает новый, PUT — обновляет существующий, DELETE — удаляет.
Проблемы?
Да, есть небольшая проблема с применением REST на практике. Проблема эта называется HTML.
PUT/DELETE запросы можно отправлять посредством XMLHttpRequest, посредством обращения к серверу «вручную» (скажем, через curl или даже через telnet), но нельзя сделать HTML-форму, отправляющую полноценный PUT/DELETE-запрос.
Дело в том, спецификация HTML не позволяет создавать формы, отправляющие данные иначе, чем через GET или POST. Поэтому для нормальной работы с другими методами приходится имитировать их искусственно. Например, в Rack (механизм, на базе которого Ruby взаимодействует с веб-сервером; с применением Rack сделаны Rails, Merb и другие Ruby-фреймворки) в форму можно добавить hidden-поле с именем «_method», а в качестве значения указать название метода (например, «PUT») — в этом случае будет отправлен POST-запрос, но Rack сможет сделать вид, что получил PUT, а не POST.
Библиотека Requests в Python
Библиотека requests фактически является стандартом для выполнения HTTP-запросов.
Он абстрагирует сложности создания запросов за красивым и простым API, чтобы вы могли сосредоточиться на взаимодействии с сервисами, и использовании данных в своем приложении.
Вы узнаете как эффективно использовать запросы и как предотвратить замедление запросов к внешним службам вашего приложения.
Из данного руководства вы узнаете как:
В статье добавлено столько информации, сколько нужно для понимания функций и приведенных примеров.
Для того, чтобы ознакомится с базовыми понятиями работы HTTP-запросов, можно прочитать статью w3schools.
Начало работы с библиотекой requests
Начнем с установки библиотеки запросов. Для этого в консоли выполните команду:
Если вы используете pipenv для управления пакетами python, то выполните команду:
После установки библиотеки, вы можете импортировать ее в приложение:
Теперь, когда всё настроено, самое время начать работать с библиотекой. Первой целью будет научиться как делать GET-запросы.
GET-запросы
HTTP-методы, такие как GET и POST, определяют какое действие вы пытаетесь выполнить при отправке запроса. Помимо GET и POST есть и другие и методы, которые мы будем позже использовать в этой статье.
Поздравляем! Вы сделали первый запрос. Давайте теперь погрузимся немного глубже в ответ на этот запрос.
Объект Response
Давайте сделаем тот же запрос, но на этот раз сохраним его в переменную, чтобы мы могли более подробно изучить его атрибуты и поведение:
Код ответа HTTP
Например, статус 200 OK означает, что ваш запрос был успешно выполнен, а статус 404 NOT FOUND означает, что ресурс не найден. Есть множество других ответов сервера, которые могут дать вам информацию о том, что произошло с вашим запросом.
.status_code вернул 200 — это значит, что запрос успешно выполнен и сервер отдал вам запрашиваемые данные.
Иногда эту информацию можно использовать в коде для принятия решений:
Поэтому вы можете сделать проще последний пример, переписав if :
Техническая деталь: Этот тест истинного значения возможен благодаря тому, что __bool__() — перегруженный метод в Response.
Это означает, что стандартное поведение Response было переопределено для учета кода состояния (ответа сервера) при опеределении значения истинности.
Например, статус 204 говорит о том, что запрос был успешным, но в теле ответа нет содержимого.
Поэтому убедитесь, что вы используете этот сокращенный вид записи, только если хотите узнать был ли запрос успешен в целом. А затем обработать код состояния соответствующим образом.
Что еще прочитать: Если вы не знакомы f-строками в Python, то я призываю вас воспользоваться ими, так это отличный способ упростить отформатированные строки.
Теперь вы знаете многое о том, что делать с кодом ответа от сервера. Но когда вы делаете GET-запрос, вы редко заботитесь только об ответе сервера — обычно вы хотите увидеть больше.
Далее вы узнаете как просмотреть фактические данные, которые сервер отправил в теле ответа.
Content
Ответ на Get-запрос, в теле сообщения часто содержит некую ценную информацию, известную как «полезная нагрузка» («Payload»). Используя атрибуты и методы Response, вы можете просматривать payload в разных форматах.
Вы можете делать многое с кодом состояний и телом сообщений. Но если вам нужна дополнительная информация, такая как метаданные о самом ответе, то вам нужно взглянуть на заголовки ответа.
Заголовки
.headers возвращает похожий на словарь объект, позволяющий получить доступ к значениям объекта по ключу. Например, чтобы получить тип содержимого ответа, вы можете получить доступ к Content-Type:
Используя ключ content-type или Content-Type — вы получите одно и то же значение.
Теперь вы узнали основное о Response. Вы увидели его наиболее используемые атрибуты и методы в действии. Давайте сделаем шаг назад и посмотрим как изменяются ответы при настройке Get-запросов.
Параметры строки запроса
Вы даже можете передать значение в байтах:
Строки запроса полезны для параметризации GET-запросов. Вы также можете изменить ваши запросы, добавив или изменив отправляемые вами заголовки.
Заголовки запросов
Заголовок Accept сообщает серверу, какие типы контента может обрабатывать ваше приложение.
Прежде чем вы узнаете больше способов настройки запросов, давайте расширим кругозор, изучив другие методы HTTP.
Другие методы HTTP
В стороне от GET, есть другие популярные методы включая: POST, DELETE, PUT, HEAD, PATCH и OPTIONS. Библиотека Requests предоставляет похожие возможности для работы с каждым из вышеперечисленных методов HTTP:
Каждый вызов функции делает запрос в службу httpbin с использованием соответствующего метода HTTP. Для каждого метода вы можете проверить ответ:
Заголовки, тело ответов, коды состояния и многое другое возвращается в ответе для каждого метода. Далее вы познакомитесь с методами PUT, POST и PATCH и узнаете, чем они отличаются от других типов запросов.
Тело сообщения
Согласно спецификации HTTP — POST, PUT и менее распространенный метод PATCH, передают свои данные через тело сообщения, а не через параметры в строке запроса. Используя эти запросы, вы передатите полезную нагрузку в параметр data соответствующей функции.
Data принимает словарь, список кортежей, байтов или файлоподобный объект.
Вы можете захотеть адаптировать данные, которые отправляете в теле запроса, к конкретным потребностям сервиса, с которым взаимодействуете.
Вы также можете отправить данные в списке кортежей:
Проверка вашего запроса
Когда вы делаете запрос, библиотека requests подготавливает данные, перед тем как отправить их на сервер. Подготовка включает в себя такие вещи, как сериализация JSON и проверка заголовков.
Проверка PreparedRequest дает вам доступ ко всей информации о выполняемом запросе, такой как полезная нагрузка, URL, заголовки, аутенфикация и многое другое.
До сих пор, вы делали много разных видов запросов, но у них всех было одно общее — это неаутентированные запросы к публичным API. Многие службы, с которыми вы можете столкнуться, захотят, чтобы вы каким-то образом идентифицировали себя.
Аутентификация
Одним из примеров API, которые требует аутентификации, является GitHub’s Authenticated User API. Это конечная точка предоставляет информацию о профиле аутентифицированного пользователя. Чтобы сделать запрос к Authenticated User API, вы можете передать свое имя пользователя и пароль в кортеже get() :
Здесь ваш пользовательский механизм TokenAuth получает токен, а затем включает этот токен в заголовок X-TokenAuth вашего запроса.
Проверка SSL-сертификата
В любое время, когда вы отправляете или получаете данные — важна безопасность. Вы общаетесь с защищенными сайтами через HTTP, устанавливая зашифрованное соединение с использованием SSL, что означает, что проверка SSL-сертификата целевого сервера имеет решающее значение.
Хорошей новостью является то, что requests делает это за вас по умолчанию. Однако, в некоторых случаях, вы можете изменить это поведение.
Если вы хотите отключить проверку SSL-сертификата, вы передаете False в параметр verify функции requests :
Библиотека requests даже предупреждает вас, когда вы делаете небезопасный запрос, чтобы помочь сохранить ваши данные в безопасности.
Производительность
Время ожидания
Когда вы отправляете запрос во внешнюю службу, вашей системе потребуется дождаться ответа, прежде чем двигаться дальше. Если ваше предложение слишком долго ожидает ответа — запросы к службе могут быть скопированы, пользовательский интерфейс может пострадать или фоновые задания могут зависнуть.
В первом запросе, время ожидания истекает через одну секунду. Во втором — через 3,05 секунд.
Вы также можете передать кортеж тайм-ауту. Первый элемент в кортеже является тайм-аутом соединения (время, которое позволяет установить клиенту соединение с сервером), а второй элемент — время ожидания чтения (время ожидания ответа после того, как клиент установил соединение):
Если запрос устанавливает соединение в течение 2 секунд и получает данные в течение 5 секунд после установки соединения, то ответ будет возвращен. Если время ожидания истекло — функция вызовет исключение Timeout :
Ваша программа может перехватить исключение и ответить соответствующим образом.
Объект Session
Сеансы используются для сохранения параметров в запросах. Например, если вы хотите использовать одну и ту же аутентификацию для нескольких запросов, вы можете использовать сеанс:
Каждый раз, когда вы делаете запрос в сеансе, после того, как он был инициализирован с учетными данными аутентификации, учетные данные будут сохраняться.
Максимальное количество попыток
В случае сбоя запроса, вы можете захотеть, чтобы приложение отправило запрос повторно. Однако requests не делает этого за вас по умолчанию. Чтобы реализовать эту функцию, вам необходимо реализовать собственный транспортный адаптер.
Когда вы монтируете HTTPAdapter и github_adapter в Session — Session будет придерживаться этой конфигурации в каждом запросе к https://api.github.com.
Время ожидания, транспортные адаптеры и сеансы, предназначены для обеспечения эффективности вашего кода и отказоустойчивости приложения.
Заключение
Вы прошли долгий путь в изучении мощной библиотеки Requests в Python.
Поскольку вы узнали как использовать запросы, у вас появилась возможность исследовать широкий мир веб-сервисов, создавать потрясающие приложения и использовать данные, которые они предоставляют.