Request url что это
Python Requests
Введение в тему
Модуль python requests – это общепринятый стандарт для работы с запросами по протоколу HTTP.
Этот модуль избавляет Вас от необходимости работать с низкоуровневыми деталями. Работа с запросами становится простой и элегантной.
В этом уроке будут рассмотрены самые полезные функций библиотеки requests и различные способы их использования.
Перед использованием модуля его необходимо установить:
Создание get и post запроса
Сперва необходимо добавить модуль Requests в Ваш код:
Создадим запрос и получим ответ, содержащий страницу и все необходимые данные о ней.
В переменную response попадает ответ на запрос. Благодаря этому объекту можно использовать любую информацию, относящуюся к этому ответу.
Сделать POST запрос так же очень просто:
Другие виды HTTP запросов, к примеру: PUT, DELETE, и прочих, выполнить ничуть не сложнее:
Передача параметров в url
Иногда может быть необходимо отправить различные данные вместе с запросом URL. При ручной настройке URL, параметры выглядят как пары ключ=значение после знака «?». Например, https://www.google.ru/search?q=Python. Модуль Requests предоставляет возможность передать эти параметры как словарь, применяя аргумент params. Если вы хотите передать q = Python и foo=’bar’ ресурсу google.ru/search, вы должны использовать следующий код:
Здесь мы видим, что URL был сформирован именно так, как это было задумано.
Пара ключ=значение, где значение равняется None, не будет добавлена к параметрам запроса URL.
Так же есть возможность передавать в запрос список параметров:
Содержимое ответа response
Библиотека автоматически пытается определить кодировку ответа основываясь на его заголовках. Узнать, какую кодировку выбрал модуль, можно следующим образом:
Бинарное содержимое ответа
Существует возможность просмотра ответа в виде байтов:
При передаче со сжатием ответ автоматически декодируется для Вас.
Содержимое ответа в json
Так же в Requests есть встроенная обработка ответов в формате JSON:
import requests
import json
response = requests.get(‘http://api.open-notify.org/astros.json’)
print(json.dumps(response.json(), sort_keys=True, indent=4))
#Вывод:
«name»: «Mark Vande Hei»
«name»: «Oleg Novitskiy»
Необработанное содержимое ответа
response.iter_content будет автоматически декодировать сжатый ответ. Response.raw — чистый набор байтов, неизменённое содержимое ответа.
Пользовательские заголовки
Если необходимо установить заголовки в HTTP запросе, передайте словарь с ними в параметр headers. Значения заголовка должны быть типа string, bytestring или unicode. Имена заголовков не чувствительны к регистру символов.
В следующем примере мы устанавливаем информацию об используемом браузере:
Более сложные post запросы
Существует способ отправить данные так, будто это результат заполнения формы на сайте:
Параметр data может иметь произвольное количество значений для каждого ключа. Для этого необходимо указать data в формате кортежа, либо в виде dict со списками значений.
Если нужно отправить данные, не закодированные как данные формы, то передайте в запрос строку вместо словаря. Тогда данные отправятся в изначальном виде.
Post отправка multipart encoded файла
Запросы упрощают загрузку файлов с многостраничным кодированием (Multipart-Encoded):
Вы можете установить имя файла, content_type и заголовки в явном виде:
Можете отправить строки, которые будут приняты в виде файлов:
Коды состояния ответа
Возможно, наиболее важные данные (первые – уж точно), которые вы можете получить, используя библиотеку requests, является код состояния ответа.
Так, 200 статус означает, что запрос выполнен успешно, тогда как 404 статус означает, что ресурс не найден.
Важнее всего то, с какой цифры начинается код состояния:
.status_code вернул 200 — это означает, что запрос успешно выполнен и сервер вернул запрашиваемые данные.
При желании, такую информацию можно применить в Вашем Пайтон скрипте для принятия решений:
Если код состояния response равен 200, то скрипт выведет «Успех!», но, если он равен 404, то скрипт вернёт «Страница куда-то пропала…».
Если применить модуль Response в условном выражении и проверить логическое значение его экземпляра (if response) то он продемонстрирует значение True, если код ответа находится в диапазоне между 200 и 400, и False во всех остальных случаях.
Упростим код из предыдущего примера:
Данный способ не проверяет, что код состояния равен именно 200.
Причиной этого является то, что response с кодом в диапазоне от 200 до 400, такие как 204 и 304, тоже являются успешными, ведь они возвращают обрабатываемый ответ. Следовательно, этот подход делит все запросы на успешные и неуспешные – не более того. Во многих случаях Вам потребуется более детальная обработка кодов состояния запроса.
Заголовки ответов
Мы можем просматривать заголовки ответа сервера:
5 Запрос (Request).
Сообщение запроса от клиента к серверу содержит в первой строке: метод, который нужно применить к ресурсу, идентификатор ресурса и используемую версию протокола.
5.1 Строка запроса (Request-Line).
Строка запроса (Request-Line) начинается с лексемы метода, затем следует запрашиваемый URI (Request-URI), версия протокола и CRLF. Эти элементы разделяются SP. В строке запроса (Request-Line) не допустимы CR и LF, исключение составляет конечная последовательность CRLF.
5.1.1 Метод (Method).
Лексема метода указывает метод, который нужно применить к ресурсу, идентифицированному запрашиваемым URI (Request-URI). Метод чувствителен к регистру.
Список методов, применимых к ресурсу, может быть указан в поле заголовка Allow (раздел 14.7). Возврашаемый код состояния ответа всегда сообщает клиенту, допустим ли метод для ресурса в настоящее время, так как набор допустимых методов может изменяться динамически. Серверам СЛЕДУЕТ возвратить код состояния 405 (Метод не дозволен, Method Not Allowed), если метод известен серверу, но не применим для запрошенного ресурса, и 501 (Не реализовано, Not Implemented), если метод не распознан или не реализован сервером. Список методов, известных серверу, может быть указан в поле заголовка ответа Public (раздел 14.35).
Методы GET и HEAD ДОЛЖНЫ поддерживаться всеми универсальными (general-purpose) серверами. Остальные методы опциональны; однако, если вышеупомянутые методы реализованы, то они ДОЛЖНЫ иметь семантику, описанную в разделе 9.
5.1.2 Запрашиваемый URI (Request-URI).
Три опции для запрашиваемого URI (Request-URI) зависят от характера запроса. Звездочка «*» означает, что запрос обращается не к специфическому ресурсу, а к серверу непосредственно, и допускается только в том случае, когда используемый метод не обязательно обращается к ресурсу. В качестве примера:
absoluteURI необходим, когда запрос производится через прокси-сервер. Прокси-сервер перенаправляет запрос на сервер или обслуживает его, пользуясь кэшем, и возвращает ответ. Обратите внимание, что прокси-сервер МОЖЕТ переслать запрос другому прокси-серверу или непосредственно серверу, определенному absoluteURI. Чтобы избежать зацикливания запроса прокси-сервер ДОЛЖЕН быть способен распознавать все имена сервера, включая любые псевдонимы, локальные разновидности, и числовые IP адреса. Request-Line может быть, например, таким:
Чтобы обеспечить переход к absoluteURI во всех запросах в будущих версиях HTTP, все HTTP/1.1 серверы ДОЛЖНЫ принимать absoluteURI в запросах, хотя HTTP/1.1 клиенты будут генерировать их только в запросах к прокси-серверам.
Если прокси-сервер получает запрос без пути в Request-URI, и метод запроса допускает форму запроса «*», то последний прокси-сервер в цепочке запросов ДОЛЖЕН передать запрос, в котором Request-URI равен «*». Например запрос был бы передан прокси-сервером в виде после соединения с портом 8001 хоста «www.ics.uci.edu».
Request-URI передается в формате, определенном в разделе 3.2.1. Первоначальный сервер ДОЛЖЕН декодировать Request-URI, чтобы правильно интерпретировать запрос. Серверам СЛЕДУЕТ отвечать на недопустимые Request-URI соответствующим кодом состояния.
В запросах, которые передаются далее, прокси-сервера никогда НЕ ДОЛЖНЫ перезаписывать часть «abs_path» запрашиваемого URI (Request-URI), за исключением случая, отмеченного выше, когда пустой abs_path заменяется на «*», независимо от внутренней реализации прокси-сервера.
Обратите внимание: правило «ничто не перезаписывать» предохраняет прокси-сервера от изменения значения запроса, в котором первоначальный сервер неправильно использует не зарезервированные символы URL для своих целей. Реализаторам следует знать, что некоторые до-HTTP/1.1 прокси-сервера, как известно, перезаписывали Request-URI.
5.2 Ресурс, идентифицируемый запросом.
Первоначальные HTTP/1.1 сервера ДОЛЖНЫ учитывать, что точный ресурс, идентифицированный интернет-запросом определяется исследованием как Request-URI, так и поля заголовка Host.
Первоначальный сервер, который не позволяет ресурсам отличаться по запрошенному хосту (host), МОЖЕТ игнорировать значение поля заголовка Host. (Но смотрите раздел 19.5.1 для других требований по поддержке Host в HTTP/1.1).
Первоначальный сервер, который различает ресурсы, основанные на запрошенном хосте (иногда называемые виртуальными хостами или vanity hostnames) ДОЛЖЕН использовать следующие правила для определения запрошенного в HTTP/1.1 запросе ресурса:
Получатели HTTP/1.0 запроса, в котором недостает поля заголовка Host, МОГУТ пытаться использовать эвристику (например, исследовать путь в URI на предмет уникальности на каком-либо из хостов) чтобы определить какой точно ресурс запрашивается.
5.3 Поля заголовка запроса.
Поля заголовка запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте. Эти поля действуют как модификаторы запроса с семантикой, эквивалентной параметрам вызова методов в языках программирования.
Имена полей заголовка запроса (Request-header) могут быть надежно расширены только в сочетании с изменением версии протокола. Однако, новые или экспериментальные поля заголовка могут получить семантику полей заголовка запроса (Request-header), если все стороны соединения распознают их как поля заголовка запроса (Request-header). Нераспознанные поля заголовка обрабатываются как поля заголовка объекта (entity-header).
H Анатомия HTTP-запроса в черновиках
Каждый хороший разработчик должен знать, что происходит под капотом после того, как пользователь введет URL сайта в адресной строке браузера и нажмет кнопку «Перейти». На самом деле это самый частый вопрос на собеседовании. В этой статье мы разберем, что происходит во время обработки HTTP-запроса.
Терминология
Для того, чтобы понять, как обрабатывается запрос вам нужно знать следующие определения:
Шаг 1: поиск DNS
На самом деле веб-адреса представляют собой простую строку, которую выглядит как-то так: 216.58.198.174. Если вы перейдете по этому адресу с помощью браузера, то откроется Google. Доменное имя (google.com) это просто псевдоним, который позволяет пользователю легче запомнить адрес.
Итак, когда пользователь вводит доменное имя (например, google.com), браузер делает запрос к DNS и получает IP-адрес, который связан с этим именем.
Думайте о DNS как о телефонной книге. Вместо того, что запоминать номер Вани, вы можете записать его в телефонную книгу. Затем вы можете просто нажать «позвонить Ване» и ваш телефон найдет его номер в базе, и позвонит по этому номеру. В этой аналогии имя «Ваня» — это доменное имя, его номер — это IP-адрес, а телефонная книга — это DNS.
Шаг 2: выполнение запроса
После того, как браузер получил IP-адрес сервера от DNS, он может приступить к созданию запроса. Запрос содержит в себе заголовок и также может содержать тело запроса (например, данные из формы, которую отправил пользователь).
Заголовок содержит в себе следующие параметры:
В итоге запрос будет выглядеть так:
Дополнительная информация может быть добавлена ниже. Они представлены в виде пар ключ/значение, где ключ — это идентификатор, название, а значение — собственно сам кусочек информации. Пример ниже включают в себя информацию о браузере пользователя (user-agent), куки (cookies), тип содержимого (content type), хост (host), которое в данном случае является названием домена и т.д. Полный HTTP-запрос выглядит как-то так:
Шаг 3: ответ сервера
После того, как сервер получил запрос, он генерирует ответ. Так же как и запрос ответ содержит различную информацию, включая:
Обычный ответ сервера выглядит как-то так:
Поле Content-Type говорит, браузеру, какой тип содержимого ему следует ожидать. В данном случае это простой HTML. Таким образом, браузер узнает, что ему нужно отрендерить и показать HTML. Тип содержимого может быть также указан как картинка, видео, JSON и т.д. Это поле говорит браузеру, как нужно обработать полученную информацию.
HTML также подключает различные ресурсы, такие как изображения, видео, шрифты или внешние CSS и JavaScript-файлы. Браузер отправляет запросы к серверу для получения этих ресурсов, а затем размещает их на странице. Если вы откроете инструменты разработчика в Google Chrome (Ctrl+Shift+J) и откроете какой-нибудь сайт, то увидите запросы, которые выполнил браузер (вкладка Network).
Заключение
Итак, теперь у вас есть общее представление как работают HTTP-запросы. Конечно все становится намного сложнее, когда дело доходит до отправки формы и загрузки файлов, но это уже совсем другая история.
комментарии ( 9 )
Во-первых, для «оригинал тут» есть выбор публикация/перевод.
Во-вторых статей такого вида уже даже на хабре тонна и непонятно зачем этот мусор нужен ещё раз, да ещё и в хабе «программирование».
Это не считая того, что это же написано в help’е: https://habrahabr.ru/info/help/posts/:
Если нажать на слово «Публикацию» во фразе «Хочу опубликовать публикацию», то ниспадающее меню предложит вам выбрать второй доступный для создания вид записи — «Перевод». Механизм создания тот же, что и у публикации, но есть два дополнительных поля — «Автор оригинала» (тут надо указать имя автора оригинального текста) и «Ссылка на оригинал» (здесь — URL страницы оригинала).
Статья очень-очень базовая. На мой взгляд, ее польза несколько сомнительна, но тем не менее, позволю себе оставить пару замечаний.
Мне кажется, что упоминание того, что заголовок Host с доменным именем используется веб-сервером для возможности одновременной работы нескольких веб-ресурсов на одном IP-адресе заслуживает упоминания даже в такой базовой статье. Хотя бы для того, чтобы новичку было понятно, почему при блокировке одного IP блокируются другие сайты, хостящиеся на том же адресе.
«Заголовок» — это на самом деле «строка запроса» (request line), чтобы не создавать путаницы с заголовками (headers), это проблема не перевода, а оригинала. «Пары ключ-значение» — это как раз заголовки.
И еще, мне кажется, что в самых базовых статьях стоит освещать тот факт, что уже 17 лет протокол HTTP/1.1, позволяет не закрывать соединение после каждого запроса-ответа для того чтобы ускорить работу сети, избавившись от затрат на переподключение для каждого ресурса. Для того, чтобы сервер и клиент понимали, когда данные завершились, используется, на мой взгляд один из самых главных заголовков Content-length, значением которого является размер тела сообщения в байтах. Если игнорировать этот заголовок в своих приложениях, даже при указании HTTP/1.1 в строке ответа сервера, соединение будет фактически HTTP/1.0 (Конечно, если не указан Transfer-Encoding, но вот это уже advanced ИМХО) Вообще, последняя спека написана вполне себе человеческим языком и не слишком длинная.
… а что, новичкам можно давать ошибочную информацию?
А почему в ответ на вопрос «что происходит» выбран именно этот уровень абстракции? Почему не разбираются детали TCP/IP соединения? Или HTTPS, которого сейчас много? Или почему не разбирается, что происходит в браузере между моментом нажатия на Enter и отправкой собственно HTTP-запроса?
В конце концов, почему переход на страницу в браузере приравнивается к HTTP-запросу?
+1
Начиная про то, что запрос имён в DNS не такая и простая штука, как кажется, заканчивая тем, что на шаге 2 перед формированием запроса происходит хотя бы банальное подключение к серверу.
Очередная статья, очень низкого уровня, имхо не годная для хабра, а вот для начинающих эникеев/домохозяек сойдет.
> Анатомия HTTP-запроса
И уж точно статью нельзя назвать «Анатомией http», а так — «беглый осмотр веб-технологий»
Время указано в том часовом поясе, который установлен на Вашем устройстве.
Библиотека Requests:
эффективные и простые
HTTP-запросы в Python
1. Основные возможности библиотеки Requests
Модуль разработан с учетом потребностей современных web-разработчиков и актуальных технологий. Многие операции автоматизированы, а ручные настройки сведены к минимуму.
Для понимания инструментария библиотеки перечислим ее основные возможности:
– поддержка постоянного HTTP-соединения и его повторное использование;
– применение международных и национальных доменов;
– использование Cookie : передача и получение значений в формате ключ: значение ;
– автоматическое декодирование контента;
– SSL верификация;
– аутентификация пользователей на большинстве ресурсов с сохранением;
– поддержка proxy при необходимости;
– загрузка и выгрузка файлов;
– стриминговые загрузки и фрагментированные запросы;
– задержки соединений;
– передача требуемых заголовков на web-ресурсы и др.
В целом, практически любая задача, которая возникает у разработчика, нашла свое отражение в коде библиотеки. Важно понимать, что Requests не предназначен для парсинга ответа сервера (для этого применяют другие модули, например, Beautiful Soup ).
Библиотека 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.
Поскольку вы узнали как использовать запросы, у вас появилась возможность исследовать широкий мир веб-сервисов, создавать потрясающие приложения и использовать данные, которые они предоставляют.