[БЕЗ_ЗВУКА]
[БЕЗ_ЗВУКА] В этом видео мы рассмотрим библиотеку requests и ее возможности.
Для начала импортируем модули requests.
И попробуем выполнить простой get запрос.
Для этого нам нужно написать requests.get и обратимся к ресурсу httpbin.org.
Посмотрим, что же он нам выведет.
В итоге мы получили http ответ со следующей структурой.
Давайте допустим, что мы хотим выполнить post запрос.
Для этого, вместо того чтобы вызывать метод get,
мы вызываем метод post и делаем post запрос.
Посмотрим, что же нам вернет.
Таким образом, мы выполнили post запрос.
Что же делать, если нам необходимо передать параметры?
Для того чтобы передать get параметры, нам необходимо указать params.
Давайте попробуем.
Мы выполнили get запрос с get параметрами —
key1 со значением value1 и key2 со значением value2.
Для того чтобы передать данные в post, put, patch запросах,
нам нужно передать в соответствующие методы поле data.
Посмотрим на http ответ.
Мы видим, что мы передали данные
в этом запросе, это можно увидеть в этом поле.
Что же делать, если мы хотим передать json?
Это можно сделать двумя путями.
Либо руками — сериализовать json и передать в поле data,
либо использовать встроенный механизм в библиотеку requests и
передать поле json, которая сама всё за вас сделает.
Давайте посмотрим.
Мы видим, что в поле data пришел сериализованный json,
а в поле json у нас отобразился наш ключик и наше значение.
Давайте теперь рассмотрим, как же нам передать файл на сервер.
Для этого нам необходимо объявить переменную files, которая будет являться
словарем, где ключ — это ключ, по которому мы сможем получить файл на сервере.
Дальше, это имя файлика и его дескриптор.
Потом эту переменную необходимо передать в поле files в метод requests.
Давайте посмотрим, что же будет у нас в ответе.
Мы видим, что сервер принял файл
с ключом файл и вывел там наш test content.
Теперь давайте рассмотрим, как же нам передать заголовки.
Для этого нам необходимо объявить переменную, которая будет являться диктом,
ключ — это будет имя заголовка, а значением будет значение этого заголовка.
Для того чтобы передать заголовки, нужно эту переменную передать в поле headers.
Посмотрим, что же нам вернет наш сервер.
Мы передали user-agent, и мы видим,
что в заголовках у нас пришел User-Agent с нашими значениями my-app/0.0.1.
Мы рассмотрели, как же нам передавать различные параметры в запрос.
Теперь давайте рассмотрим возможности ответа.
Для того чтобы получить данные http ответа,
существует несколько способов.
Это text, content и json.
Давайте посмотрим, что же нам выведет этот пример.
Text вернет нам данные с типом string.
Собственно, мы это видим.
Content вернет нам массив byte.
А json нам вернет словарь.
Также можно посмотреть статус ответа.
То есть с каким статусом вернулся наш http ответ.
Если необходимо, можно сравнить этот ответ с набором ответов из библиотеки requests.
Посмотрим на статус 200, мы сравнили его
с requests.codes.ok и в итоге получили True.
В коде на самом деле плохо сравнивать с какими-то числами,
это зачастую непонятно и лучше всего использовать всегда константы.
Иногда очень удобно,
чтобы при некорректном http ответе мы получали исключение.
Для этого есть метод raise for status.
Давайте попробуем обратиться на httpbin.org,
чтобы он нам вернул, например, статус 404.
Выполним этот фрагмент кода и увидим, что у нас ответ 404 и мы получили исключение.
HTTPError 404 NOT FOUND.
Мы еще можем посмотреть заголовки http ответа.
Для этого нам нужно получить поле headers.
Это словарь, и мы видим все заголовки, которые нам пришли.
Давайте теперь рассмотрим другой пример.
Допустим, мы хотим обратиться к github.com.
Мы в итоге видим,
что мы обращались на http github.com, а попали мы на https github.com.
Давайте рассмотрим, почему так происходит.
Выполним этот фрагмент кода и видим,
что мы обращаемся на http, а в итоге мы попали на https.
И со статусом 200, но в history появилась история о том, что у нас был ответ 301.
То есть когда мы обращались к ресурсу по протоколу http,
он нам кинул 301 redirect и сказал,
что в дальнейшем обращайся на https github.com.
Это было зафиксировано в поле history.
В случае, если нам не нужно такое поведение,
то необходимо передать поле allow redirects = False,
и давайте посмотрим, что произойдет.
Статус ответа 301 и в history пусто,
потому что дальше он не пошел выполнять никакие действия.
Теперь рассмотрим cookie.
Что вообще такое cookie?
Это некоторые данные, которые будут передаваться в каждом запросе,
то есть мы делаем запрос на сервер, он нам говорит, что, пожалуйста,
поставь куку с именем 1 со значением 1 и все дальнейшие запросы
выполняй с этой кукой до какого-то момента.
Зачем это нужно?
Например, для авторизации.
Мы когда обращаемся на сервер, вводим свой логин, пароль,
он нам дает некий ключик, который ассоциируется в дальнейшем с нами.
Мы ходим с этим ключиком, и он понимает, что это тот пользователь,
который ввел логин и пароль.
Давайте посмотрим.
Для того чтобы передать куки, нам необходимо объявить словарь и
ключ — это будет имя куки и значение словаря — это будет значение куки.
Давайте посмотрим.
В итоге нам ответили, что мы пришли с кукой
с именем cookies_are и со значением working.
Давайте теперь рассмотрим понятие сессии.
Когда мы объявляем сессию, то все следующие запросы будут
выполняться с теми же параметрами, что и предыдущие.
То есть, например, мы объявили сессию и сделали get запрос в этой сессии.
И нам сервер установил куку с именем sessioncookie и значением 123456789.
То в этой сессии все следующие запросы будут также выполняться с этой кукой.
Давайте посмотрим.
Мы видим, что следующий запрос на http
org/cookies у нас уже пошел с кукой sessioncookie 123456789,
и об этом свидетельствует наш http ответ.
То же самое происходит со всеми параметрами, например, с хедерами.
Мы в сессии установили header x-test со значением true.
И следующий запрос будет также выполнен с этим заголовком,
то есть в ответе у нас будут оба заголовка.
Давайте попробуем.
В итоге мы сделали запрос с этими заголовками.
В этом видео мы рассмотрели билиотеку http requests и ее возможности.
[ЗВУК] [БЕЗ_ЗВУКА]