Содержание

Библиотека Requests Python 3 — GET-запросы

В этой статье мы рассмотрим библиотеку Python Requests, которая позволяет отправлять HTTP-запросы в Python.

Работа API основана на отправке HTTP-запросов и получение ответов. Библиотека Requests позволяет использовать API в Python. В качестве примера я продемонстрирую принцип работы Translate API.

Каждый раз, когда вы переходите на веб-страницу, браузер отправляет несколько запросов на сервер. В ответ он отсылает данные для рендеринга страницы, которые браузер использует для ее отображения.

Механизмы работает следующим образом: клиент (например, браузер или скрипт Python, использующий библиотеку Requests) отправляет данные на сервер, расположенный по указанному URL. Сервер обрабатывает полученную информацию и возвращает ответ клиенту.

В запросе клиент также указывает, какой метод будет использован для передачи. Самые распространенные методы: GET, POST и PUT.

GET-запросы предназначены только для чтения данных без внесения каких-либо изменений.

POST и PUT-запросы предназначены для изменения данных на сервере. Так, например, Stripe API применяет POST-запросы для создания новых платежей, чтобы пользователь мог что-то купить в вашем приложении.

В этой статье рассматриваются только запросы GET, потому что мы не будем изменять отправляемые данные на сервере.

Прежде всего, установим библиотеку Python Requests, используя менеджер пакетов pip. Сначала создайте виртуальную среду.

Для начала используем библиотеку Python Requests для чего-то простого: отправим запрос на сайт Scotch.io. Создайте файл script.py и добавьте в него приведенный ниже код.

import requests

res = requests.get('https://scotch.io')

print(res)

Приведенный выше код отправляет запрос GET на Scotch.io. Это тот же тип запроса, который браузер отправляет для просмотра веб-страницы. Отличие заключается в том, что эти запросы не могут передать HTML. Поэтому вместо него приходит необработанный HTML и другая информация из ответа, предоставленного сервером.

В данном случае мы используем функцию .get(). Но библиотека Requests содержит и другие подобные функции: .post() и .put().

Запустите файл script.py.

В ответ придет следующее:

Проверим код состояния ответа. Коды состояния HTTP варьируются от 1XX до 5XX. Скорее всего, вы сталкивались с кодами состояния 200, 404 и 500.

Что обозначает каждый из них:

  • 1XX – информация.
  • 2XX – успешно.
  • 3XX – перенаправление.
  • 4XX — Ошибка клиента.
  • 5XX — Ошибка сервера.

Обычно при выполнении запросов приходят коды состояния 2ХХ. Коды 4XX и 5XX являются ошибками. При их получении ответ расценивается как False.

Вы можете проверить результативность запроса с помощью следующего кода:

if res:
    print('Response OK')
else:
    print('Response Failed')

Чтобы увидеть ответ с ошибкой 404, измените URL-адрес на произвольные знаки. Можно проверить код состояния, выполнив:

Также можно проверить код состояния самостоятельно.

Кроме этого ответ сервера содержит заголовки. На них можно взглянуть, используя словарь HTTP-заголовков.

Заголовки отправляются вместе с запросом и возвращаются в ответе. Они сообщают клиенту и серверу, как интерпретировать отправляемые и получаемые данные.

Важно знать тип содержимого ответа сервера, поскольку оно указывает на формат отправляемых данных. Например, HTML, JSON, PDF, text и т. д. Но тип содержимого обычно обрабатывается библиотекой Requests. Это обеспечивает простой доступ к полученным данным.

Свойство res.text позволяет получить весь HTML-код, необходимый для создания домашней страницы Scotch. Если сохранить этот HTML как веб-страницу и открыть ее, то мы увидим нечто похожее на сайт Scotch.

Чтобы загрузить изображения, скрипты и таблицы стилей совершается множество запросов к одной веб-странице. Поэтому, если сохранить в файле только HTML-код, он не будет выглядеть так, как страница Scotch.io, открытая в браузере.

Мы будем использовать Yandex Translate API. После регистрации перейдите в Translate API и создайте ключ API. Получив ключ API, добавьте его в свой файл. Вот ссылка на сайт, где это можно сделать: https://yandex.ru/dev/translate/

API_KEY = 'your yandex api key'

Ключ API нужен, чтобы Яндекс мог аутентифицировать нас. Ключ API добавляется в конец URL-адреса запроса при отправке.

Чтобы узнать, какой URL-адрес нам нужно отправить для использования API, обратимся к документации Яндекса:

https://yandex.ru/dev/translate/doc/dg/reference/translate-docpage/

Здесь доступна вся информация по использованию Translate API для перевода текста.

Если в документации указан URL с амперсандами (&), вопросительными знаками (?) и знаками равенства (=), значит он предназначен для отправки GET- запросов

Параметры, размещенные в квадратных скобках ([]), не является обязательными. В данном случае format, options и callback являются необязательными. Но key, text и lang обязательны для запроса.

Добавим код для отправки на этот URL. Можно заменить созданный нами запрос следующим образом:

url = 'https://translate.yandex.net/api/v1.5/tr.json/translate'
res = requests.get(url)

Параметры можно добавить в конец URL-адреса. Но библиотека  Requests может сделать это за нас. Причем второй вариант гораздо проще.

Для его реализации создадим словарь для параметров. Понадобятся только key, text и language. Создадим словарь, используя следующие значения: API key, «Hello» для текста и «en-es» для lang (для перевода с английского на испанский).

Передадим функции dict() нужные ключи и значения:

params = dict(key=API_KEY, text='Hello', lang='en-es')

Теперь передаем словарь параметров в функцию .get().

res = requests.get(url, params=params)

После этого библиотека Requests добавит параметры к URL-адресу. Теперь используем оператор print для response text и посмотрим, что вернется в ответе.

Мы получили code (код состояния), совпадающий с кодом состояния ответа. А также language (язык), который мы указали, и перевод. Поэтому вы должны увидеть переведенный текст «Hola».

Попробуйте еще раз со значением кода языка en-fr и получите «Bonjour».

params = dict(key=API_KEY, text='Hello', lang='en-fr')

Посмотрим на заголовки этого ответа:

Заголовки отличаются, потому что мы обращаемся к другому серверу. Но в этом случае тип контента будет application/json вместо text/html. Это означает, что данные могут быть интерпретированы как JSON.

Когда application/json является типом содержимого ответа, Requests может преобразовать ответ в словарь и список.

Чтобы данные были идентифицированы как JSON, используем метод .json() для объекта ответа. Если вывести результат его работы, то будет видно, что данные выглядят одинаково, но формат отличается.

json = res.json()
print(json)

Причина этого заключается в том, что теперь это не обычный текст из res.text. Теперь это печатная версия словаря.

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

Теперь мы видим только данные этого ключа. Чтобы получить этот текст, можно использовать индекс.

Теперь единственное, что мы видим, это переведенное слово. Поэтому если изменить значения параметров, то получим разные результаты. Давайте изменим текст для перевода с Hello на Goodbye, целевой язык на испанский и отправим запрос снова.

params = dict(key=API_KEY, text='Goodbye', lang='en-es')

Попробуйте изменить API KEY, удалив один символ. После этого ключ API не будет работать. Затем попробуйте отправить запрос.

Вот что будет в коде состояния:

При использовании API необходимо проверять, все ли правильно работает, чтобы вовремя устранять возникающие ошибки.

Конечно, можно сделать гораздо больше. Но то, о чем я рассказал в этой статье, является основой большинства запросов.

Чтобы получить больше информации, зайдите на https://apilist.fun/ и увидите множество доступных API. Попробуйте использовать их совместно с Python Requests.

Данная публикация является переводом статьи «Getting Started With Python Requests — GET Requests» , подготовленная редакцией проекта.

Руководство по выбору между GET и POST

Перевод: The Definitive Guide to GET vs POST

Думаю данная статья для многих не откроет Америки, и мне она показалась какой-то немного сумбурной, поэтому пришлось ее местами сглаживать, но в качестве вводной для выбора между использованием GET или POST запроса, думаю это — то самое.

К сожалению на практике встречается множество несостыковок в использовании GET вместо POST и наоборот. Оба HTTP метода могут приводить к одинаковым результатам, но их некорректное использование может привести к неожиданным и потенциально опасным последствиям.

Поэтому, что-бы быть уверенным в том, что мы делаем все правильно, я представляю Вам руководство по выбору между GET и POST.

Давайте вспомним, что в строках запросов, пара переменная/значение, передается в GET через вот такой URL запрос:

GET /blog/?name1=value1&name2=value2 HTTP/1. 1
Host: carsonified.com

а в POST запросе она передается в теле заголовка:

POST /blog/ HTTP/1.1
Host: carsonified.com
name1=value1&name2=value2

Основы: GET против POST

Давайте введем новое слово в свой словарный запас, термин — идемпотентный (Вам не стоит лезть в википедию за его трактовкой: идемпотентность это свойство объекта проявляющееся в том, что повторное действие над этим объектом не изменяет его), а разделы 9.1, 9.3 и 9.5 RFC 2616 помогут нам составить первое правило GET против POST…

Правило #1: Используйте GET для безопасных действий и POST для небезопасных

RFC указывает Интернет браузерам на то, что пользователей необходимо предупреждать о повторном использовании POST запроса, потому что это действие потенциально небезопасно (к примеру оформление онлайн оплаты).

Однако, пока браузер соблюдает это требование RFC, может поясним почему POST должен использоваться для небезопасных действий, и почему мы не должны использовать POST для безопасных?

Просто примите к сведению то, что GET запросы используются чаще:

  1. GET запросы могут кэшироваться
  2. GET запросы могут оставаться в истории браузера
  3. GET запросы можно сохранять в своих закладках
  4. GET запросы можно передавать, распространять и т. д.
  5. GET запросы можно легко изменять

Примечание: Если Вам необходимо извлекать лучшее из обоих методов, небезопасное действие можно превратить в безопасное сделав его идемпотентным и таким образом обезопаситься от возможной проблемы многочисленных повторений запросов. Вы назначаете каждому запросу свой уникальный ID и проверяете его на сервере, был ли запрос с таким ID обработан ранее. На самом деле все небезопасные действия должны быть идемпотентными, так как пользователя не остановят никакие предупреждения.

GET против POST: копаем глубже

Правило #2: Используйте POST для операций с важной информацией

Так как в GET запросах строка запроса находится в открытом виде, мы должны заботиться о своей безопасности и о том, что пользователи будут работать с важными данными, такими как пароли или номера кредитных карт:
1. Наши пользователи могут и не догадываться об этом, передавая важные данные через URL другим лицам или когда история серфинга в их браузере может быть просмотрена другими пользователями этого компьютера (хотя это может и не сработать при работе с AJAX ориентированными сервисами).
2. Мы сами нарушаем закон о частной информации, сохраняя, к примеру, в логах своего сервера номера CV2s с кредитных карт пользователей.

Правило #3: Используйте POST для операций с большими данными

Несмотря на то, что RFC не описывает такой параметр, как длина URL, Internet Explorer упорно придерживается мнения, что максимальная длина URL не может превышать 2,048 символов, это накладывает некоторые ограничения на использование GET.

Правило #4: Используйте GET в AJAX приложениях

Когда используется XMLHttpRequest, браузеры реализуют POST как двухпроходный процесс (сперва посылают заголовок, а затем данные). Это означает, что GET запросы более отзывчивые, что так необходимо для хорошего AJAX окружения.

Итоги

Хотя правила обычно существуют для убедительных причин, хорошо бы знать то, что за ними скрывается. Я сам ненавижу правила, у которых нет объяснений и надеюсь, что все вышесказанное поможет Вам уяснить правила различий GET против POST.

Выбирая между этими двумя методами необходимо иметь некоторое чутье и я думаю следующая схема поможет Вам в этом выборе:

Golang: Выполнение HTTP запросов

В этом посте мы рассмотрим, как можно делать HTTP-запросы, используя Go. Мы будем использовать пакет net/http, который предоставляет все необходимое для создания HTTP-запросов или создания новых http-серверов. То есть, этот пакет поможет нам сделать все что связано с «http».

Чтобы проверить, что мы сделали правильные запросы, мы будем использовать httpbin, который является хорошим сервисом для тестирования наших запросов на локальных компьютерах.

Простой HTTP-запрос

Давайте сделаем очень простой GET запрос и посмотрим, как мы можем прочитать ответ. Мы отправим простой HTTP-запрос GET на https://httpbin.org/get и прочитаем ответ. Для этого мы можем просто импортировать пакет net/http и использовать вызов функции http. Get:


package main

import (
	"net/http"
	"log"
	"io/ioutil"
)

func main() {
	MakeRequest()
}

func MakeRequest() {
	resp, err := http.Get("https://httpbin.org/get")
	if err != nil {
		log.Fatalln(err)
	}

	body, err := ioutil.ReadAll(resp.Body)
	if err != nil {
		log.Fatalln(err)
	}

	log.Println(string(body))
}

Мы создали отдельную функцию MakeRequest и вызвали ее из нашей основной функции. Внутри этой функции мы передали URL-адрес http.Get и получили два значения — объект ответа и переменную с ошибками, которые могли произойти во время вызова. Мы проверили, есть ли какие-либо ошибки. Если ошибок не было, ошибка будет равна nil. Обратите внимание, что эта ошибка будет сообщаться только в том случае, если возникла проблема с подключением к серверу и получением ответа. Однако, если сервер отправляет http ответ 500 (что является внутренней ошибкой сервера), вы получите этот код состояния и сообщение об ошибке на соответствующем объекте, а не в переменной err.

Затем мы читаем resp.Body, который реализует интерфейс io.ReadCloser, и мы можем использовать ioutil.ReadAll, чтобы полностью прочитать ответ. Эта функция также возвращает два значения — байтовый срез ([]byte) и err. Опять же, мы проверяем любые возможные ошибки при чтении тела ответа. Если ошибок не было, мы печатаем тело. Обратите внимание на string(body). Здесь мы преобразуем байтовый срез в строку. Если мы этого не сделаем, log.Println будет распечатывать представление байтового фрагмента, списка всех байтов в этом фрагменте, индивидуально. Но нам нужно строковое представление. Поэтому мы идем вперед и делаем преобразование.

Мы увидим, что напечатанный вывод представляет собой JSON объект в виде строки. Итак, в следующем примере мы увидим, как мы можем отправлять и читать сообщения в формате JSON.

Отправка и получение запросов в JSON

Теперь давайте отправим сообщение в формате JSON. Как мы это сделаем? Если вы пришли из Python/Node/Ruby, вы возможно уже использовали для формирования JSON объектов (словари), далее предавали их в свою любимую библиотеку и устанавливали нужный формат передачи данных. Ваша библиотека выполняла для вас преобразование объекта в JSON и отправляла запрос с требуемыми заголовками. В Go, однако, все более явно и меньше магии, что на самом деле хорошо. Вы будете знать, что делаете и как вы это делаете.

В Go мы сначала преобразуем нашу структуру данных в байтовый срез, содержащий JSON-представление данных. Затем мы передаем его запросу с соответствующим типом контента. Давайте посмотрим на пример кода:


func MakeRequest() {

	message := map[string]interface{}{
		"hello": "world",
		"life":  42,
		"embedded": map[string]string{
			"yes": "of course!",
		},
	}

	bytesRepresentation, err := json.Marshal(message)
	if err != nil {
		log.Fatalln(err)
	}

	resp, err := http. Post("https://httpbin.org/post", "application/json", bytes.NewBuffer(bytesRepresentation))
	if err != nil {
		log.Fatalln(err)
	}

	var result map[string]interface{}

	json.NewDecoder(resp.Body).Decode(&result)

	log.Println(result)
	log.Println(result["data"])
}

Сначала мы создали message, переменная, которая представляет собой карту, содержащую string, int и другую встроенную карту. Затем мы вызвали функцию json.Marshal чтобы получить массив []byte из нашей структуры. Далее мы также делаем проверку на ошибки, которые могли возникнуть во время преобразования структуры. Затем мы делаем запрос POST, используя функцию http.Post. Мы передаем url, наш тип контента (application/json), а затем мы создаем и передаем новый объект bytes.Buffer из нашей переменной bytesRepresentation. Зачем нам здесь создавать буфер? Функция http. Post ожидает реализации io.Reader. Поэтому мы могли бы даже прочитать эту часть с диска или сети. В нашем случае мы можем просто создать буфер байтов, который реализует интерфейс io.Reader. Мы отправляем запрос и проверяем наличие ошибок.

Затем мы объявляем другую переменную result (которая также является типом map) для хранения результатов, возвращаемых из запроса. Сначала мы могли прочитать полное тело (как и в предыдущем примере), а затем сделать json.Unmarshal на нем. Однако, поскольку resp.Body возвращает объект io.Reader, мы можем просто передать его json.NewDecoder, а затем вызвать функцию Decode на нем. Помните, мы должны передать указатель на наш объект map, поэтому мы передали переменную как &result вместо result. Функция Decode также возвращает вторым параметром ошибку. Но мы предполагали, что это не имеет значения и не проверяем ее. Мы зарегистрировали result и result[«data»]. Служба httpbin отправляет различную информацию о запросе в качестве ответа.

Типы запросов HTTP протокола — GET, POST и PUT

Протокол Передачи Гипертекста (HTTP), один из протоколов стека TCP/IP, был изначально разработан для публикации и получения HTML страниц и теперь используется для распределенных информационных систем. HTTP используется во Всемирной Паутине для передачи данных и является одним из самых широко применяемых прикладных протоколов.

HTTP определяет протокол типа запрос/ответ. Когда клиент, например веб браузер, посылает сообщение запроса на сервер, HTTP протокол определяет типы сообщений, используемые клиентом для запроса веб страницы, а также типы сообщений, применяемые сервером для ответа. Тремя распространенными типами сообщений являются GET, POST и PUT.

GET — это клиентский запрос данных. Веб браузер посылает сообщение GET, чтобы извлекать страницы с веб сервера. Как показано на рисунке, как только сервер получает GET запрос, он отвечает строкой статуса, например, HTTP/1.1 200 OK, и собственно самим сообщением, основной частью которого может быть запрашиваемый файл, сообщение об ошибке, либо какая-либо другая информация.

POST и PUT используются, чтобы посылать сообщения, которые загружают данные на веб сервер. Например, когда пользователь вводит данные в форму, встроенную в веб страницу, POST включает данные в сообщение, посылаемое на сервер.

PUT загружает ресурсы или контент на веб сервер.

Будучи чрезвычайно гибким, HTTP не является безопасным протоколом. Сообщения POST загружают информацию на сервер в виде обычного текста, который может быть перехвачен и прочитан. Аналогично, ответы сервера, как правило HTML страницы, также не зашифрованы.

Для безопасной коммуникации через Интернет используется Безопасный HTTP протокол (HTTPS), чтобы получать доступ или публиковать информацию на веб сервере. HTTPS может использовать аутентификацию и шифрование, чтобы обезопасить данные, когда они перемещаются между клиентом и сервером. HTTPS определяет дополнительные правила для прохождения данных между Прикладным и Транспортным Уровнями.

Далее: E-mail Службы и Протоколы SMTP/POP

Смотрите также

Написать

Введение в REST-запросы и тестирование GET-запросов

Автор: Кристин Джеквони (Kristin Jackvony)

Оригинал статьи: http://thethinkingtester.blogspot.ru/2018/02/introduction-to-rest-requests.html

http://thethinkingtester.blogspot.ru/2018/02/testing-get-requests.html

Перевод: Ольга Алифанова.

Все больше и больше компаний переходит на микросервисы в своих приложениях. Это означает, что разные секции приложения могут иметь отдельные хранилища данных и отдельные команды для взаимодействия с ними. Преимущество такого подхода в том, что в небольшой компонент внедрять изменения куда проще, нежели менять все приложение. Это также означает, что если упадет один микросервис, оставшаяся часть приложения продолжит функционировать. К примеру, представьте, что у вас есть сайт проката велосипедов. У него есть микросервис системы бронирования, и еще один – для учета оборудования. Если микросервис оборудования упадет, пользователи все равно смогут бронировать велосипеды, используя кэшированные данные сервиса оборудования.

Большинство микросервисов используют API – программные интерфейсы приложения, которые представляют собой наборы команд, описывающих, как можно использовать службу. Большая часть API использует REST-запросы (Representational State Transfer — «передача состояния представления») для отправки и получения данных.

Однако, несмотря на широкое применение REST API в современных приложениях, многие тестировщики даже не подозревают, как легко их тестировать! Эта статья – введение в REST-запросы и их использование в тестировании API.

Зачем же тестировать REST запросы, если можно просто подождать и тестировать через интерфейс? А вот почему:

  • Тестирование REST-запросов позволит найти баги раньше, иногда еще до того, как создан интерфейс!
  • Злоумышленники отлично знают, как делать REST-запросы, и могут пользоваться ими для эксплуатации уязвимостей приложения, делая запросы, которые не позволяет UI.
  • Эти запросы легко автоматизировать, и они в несколько раз быстрее, чем UI-автоматизация (см. мою статью про API и UI-автоматизацию).

Чтобы приступить к REST-тестированию, для начала подумайте, что вы видите в URL страницы, открывая сайт. К примеру, вы можете увидеть что-то вроде https://www.foobank.com/customers/login. Легко увидеть, как URL определяет, на какую страницу вы попали:

  • https означает, что это защищенный запрос,
  • www.footbank.com – это домен, который сообщает, что вы хотите попасть на сайт Foobank,
  • customers – это первая часть пути, информирующая, что вы пользователь и переходите в раздел сайта для пользователей,
  • login – финальная часть пути, говорящая о том, что вы хотите попасть на экран авторизации.

В URL не отображается только тип выполняемого REST-запроса. Они известны, как HTTP-глаголы, и их легко понять:

  • POST добавляет новую запись в базу данных.
  • GET получает запись из базы данных.
  • PUT берет запись из базы и заменяет ее новой.
  • PATCH меняет существующую в базе запись.
  • DELETE удаляет запись из базы.

Под «записью» в этом случае понимается любая секция сгруппированных вместе данных. К примеру, это может быть почтовый адрес пользователя, или вся его контактная информация, а также вообще все, связанное с этим конкретным пользователем. То, что входит в запись, зависит от создателей API.

Начнем изучение типов запросов REST с запросов GET. Обычно их легче всего тестировать, потому что все, что мы в этом случае делаем – это получаем данные из базы. Нам не надо волноваться о том, правильно ли мы манипулируем данные – нам просто нужно их получить и проверить, что мы получаем правильный ответ.

С моей точки зрения, два лучших инструмента для тестирования REST-запросов – это Swagger и Postman. Swagger -–это фреймворк с открытым исходным кодом, позволяющий разработчикам создавать документацию для REST API. Если у вашего API есть Swagger-файл, то будет легко увидеть, какие типы запросов API позволяет, и какие параметры необходимы этим запросам. Разработчики Swagger также создали образец приложения, которое можно использовать для практики REST-запросов: http://petstore.swagger.io. Этот сайт имитирует онлайн-зоомагазин, и пользователи могут добавлять и получать информацию о своих питомцах.


Зайдя на этот сайт, вы увидите, что там доступно множество возможных запросов к Pet. давайте посмотрим на запрос GET к /pet/{petID}. Нажмите на этот запрос, а затем на кнопку «Try it out». Вы увидите, что petId – это необходимый параметр. Введите 1 в поле параметра, и нажмите на «Execute». Проскролльте вниз к секции «Response Body», и вы увидите, что сервер вернул информацию о питомце! Проскролльте немного выше и посмотрите на URL запроса: http://petstore.swagger.io/v2/pet/1. Мы будем использовать этот URL, чтобы учиться делать запросы через Postman.

Postman – лучший из известных мне инструмент тестирования REST-запросов. Он бесплатно доступен на сайте https://www.getpostman.com, а еще у него есть платная командная версия. Если у вас еще нет Postman, скачайте и запустите его.


Postman должен стартовать на открытой вкладке, настроенной на использование GET-запроса. Все, что вам теперь остается сделать – это ввести URL запроса, который мы использовали ранее, и нажать «Send». Вы должны получить ответ, аналогичный ответу на этот запрос в Swagger.

Теперь, когда мы разобрались, как работают GET-запросы, давайте подумаем, как же их тестировать! Очевидно, что мы протестировали «счастливый» сценарий, получив питомца с id 1. Что будет, если мы изменим id-параметр на 2? А если на -1? На 0? На «foo»? Тут стоит упомянуть, что Swagger Pet Store – тестовое приложение, и вы можете увидеть в нем поведение, которое в реальном приложении будет нежелательным. К примеру, я получила результат, тестируя с параметром -1. Как правило, ожидается, что ID объектов данных не могут быть отрицательными, и в реальном приложении это было бы багом.

Давайте посмотрим, что будет, если мы вообще не будем вводить параметр, и наш URL запроса будет просто выглядеть как http://petstore.swagger.io/v2/pet. Мы получим XML-ответ, который гласит «unknown». Можно также заметить, что код ответа – 405 Method Not Allowed.


Коды статуса, полученные после отправки REST-запроса, сообщают вам о поведении вашего приложения. Мы еще будем их обсуждать, а пока давайте запомним, что код 200 – это хорошо, а код, начинающийся с 4, обычно означает, что что-то пошло не так. Скажем, вы можете получить статус 404 для питомца, которого не существует. Этот статус означает, что запись не найдена.

Вернемся к Swagger Pet Store и посмотрим на еще один GET-запрос. В этот раз это запрос pets/findByStatus. Нажмите на запрос, а затем на «Try it out».


Отметим, что для выполнения этого запроса нужно выбрать статус. Давайте выберем статус «sold» и нажмем на «Execute». Если вы проскроллите вниз до окна ответа, вы увидите, что сервер вернул множество питомцев. Теперь проскролльте чуть выше и посмотрите на URL запроса:

http://petstore.swagger.io/v2/pet/findByStatus?status=sold.

Вопросительный знак в URL означает, что мы использовали параметр запроса. Это немного отличается от параметра пути, который мы наблюдали, запрашивая GET по id питомца. Параметры запроса всегда начинаются с вопросительного знака. Затем идет имя параметра, знак равенства, и значение параметра, которое мы хотим использовать.

Скопируйте запрос и запустите его в Postman. Просто нажмите на кнопку «+» вверху экрана, чтобы открыть вкладку и создать новый запрос. По умолчанию он всегда GET. Введите URL и нажмите «Send». Вы должны получить результат, аналогичный прогону запроса в Swagger.

Мы протестировали один успешный сценарий для этого запроса. Его также можно прогнать с использованием значений параметра «available» и «pending». Вы можете запустить запрос http://petstore.swagger.io/v2/pet/findByStatus?status=pending,sold и получить всех забронированных и всех проданных питомцев! А что будет, если передать в параметре «foo»? вы получите пустой набор результатов. Это отличается от ответа, который мы получали, посылая «foo» как параметр для GET-запроса питомца по ID, и демонстрирует разницу между параметром запроса и параметром пути. Если параметра пути не существует, то обычно вы получите ошибку 400. Если не существует параметра запроса, то вы получите ответ 200 и пустой набор результатов в теле ответа.

Теперь, когда вы попробовали запустить два разных GET-запроса, можно тестировать дальше, манипулируя URL запросов различным образом. К примеру, посмотреть, что будет, если вы сделаете запрос к https вместо http. Или выяснить, как поведет себя система, если вы поменяете «io» в запросе на «com», или «v2» на «v1». Можно удалить «/pet». Можно попробовать изменить тип запроса на POST или DELETE. Наблюдения за тем, что происходит, помогут вам понять, как работают REST-запросы, и даст вам пищу для идей тестирования вашего API.

Больше информации по этой теме вы можете получить в курсе Тестирование REST API

Обсудить в форуме

Как сделать запрос к API?

API InSales позволяет работать с бэк-офисом магазина, используя HTTP-запросы. При помощи API можно получать, добавлять, изменять и удалять информацию о различных объектах (например, товарах, категориях, дополнительных полях и т.д.)

Предполагается, что работа с API организована на внешнем сервере (НЕ на сервере платформы), который отправляет к серверу платформы запросы определенного типа. Для удобства в этой статье будет рассмотрена отправка запросов при помощи приложения Postman. В качестве альтернативы можно использовать Advanced REST Client.

Все доступные запросы в форматах XML и JSON описаны на api.insales.ru. Типовые запросы в формате XML с более подробным описанием можно найти на api.insales.ru.

  1. Ограничения
  2. Авторизация
  3. Общие принципы
  4. Примеры XML-запросов
  5. Примеры JSON-запросов
  6. Возможные коды ответов сервера

Ограничения

На платформе присутствует ограничение в 500 запросов к API в течение 5 минут. Время рассчитывается с момента первого запроса в серии. Количество выполненных запросов в текущем промежутке времени передается в HTTP-заголовке API-Usage-Limit (например, API-Usage-Limit: 1/500).

При достижении лимита доступ к API ограничивается до окончания текущих 5 минут. При этом в HTTP-заголовке Retry-After передается время в секундах до восстановления доступа.

Авторизация

Для отправки запросов к API необходимо создать ключ доступа.

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

Для создания ключа доступа нужно в бэк-офисе перейти в раздел «Приложения» → «Разработчикам» и нажать кнопку «Создать новый ключ доступа». При необходимости можно указать его название.

Далее в статье мы будем использовать созданные логин (идентификатор) и пароль. Их можно указывать как в адресе запроса:

https://логин:пароль@shop-47483-27.myinsales.ru/admin/orders.xml

Так и в виде HTTP-заголовка Authorization:

Authorization: Basic ZGlnaXRhbC1nb29kczpjNTFjOTA3MDdhMTNjZTNmZmYyMTNhZmJiNWNkMTI3MA==

Вместо shop-47483-27.myinsales.ru необходимо использовать технический или обычный домен вашего магазина. Его можно взять, например, из строки «Пример URL» около выданного ключа доступа.

Общие принципы

API InSales принимает POST, GET, PUT и DELETE-запросы в зависимости от выполняемого действия. Тип и адрес запроса для требуемого действия можно найти на api.insales.ru.

Текст самого запроса должен соответствовать формату XML или JSON. В зависимости от формата меняется адрес запроса и значение HTTP-заголовка Content-Type.

Для XML необходим Content-Type: application/xml

А для JSON — Content-Type: application/json

На скриншоте программы Postman показан выбранный тип запроса, адрес и заголовки. После нажатия кнопки Send появится ответ сервера InSales.

Примеры XML-запросов

Рассмотрим GET-запрос к товару с id 143570988. Такой запрос не требует передачи серверу каких-либо параметров. В качестве адреса необходимо указать https://логин:пароль@shop-47483-27.myinsales.ru/admin/products/143570988.xml

В ответ сервер пришлёт всю доступную информацию об этом товаре.

 

PUT-запрос служит для обновления данных выбранного объекта. Для обновления названия того же товара с id 143570988 потребуется отправить запрос с телом

<?xml version=»1.0″ encoding=»UTF-8″?>
<product>
<title>Новое название</title>
</product>

В ответ сервер пришлёт обновлённую информацию о товаре (в том числе новое название). Соответственно, в бэк-офисе также будет отображаться новое название товара. В ответе виден код 200, что означает успешное выполнение операции.

Примеры JSON-запросов

Запросы в формате JSON отличаются адресом и заголовком Content-Type.

GET-запрос отправляется на адрес https://логин:пароль@shop-47483-27.myinsales.ru/admin/products/143570988.json . Ответ, соответственно, также будет этом формате.

 

Тело PUT-запроса на обновление названия товара выглядит следующим образом:

{

    «product»: {

        «title»: «Новое название»

    }

}

Возможные коды ответов сервера

  • 200 — штатный ответ на операцию; означает, что никаких ошибок не возникло
  • 201 — в некоторых случаях при создании объектов может вернуться этот код; по смыслу не отличается от кода 200
  • 400 — некорректный HTTP-запрос, сервер не смог его обработать
  • 401 — не удалось авторизоваться (необходимо проверить логин и пароль)
  • 403 — нет прав для данной операции (необходимо проверить настройки прав для приложения)
  • 404 — запрашиваемый объект не найден (возможно, его уже удалили или указан неверный id объекта)
  • 500 — внутренняя ошибка сервера (возможно, вы некорректно сформировали запрос или что-то сломалось на нашей стороне; необходимо обратиться в тех поддержку)
  • 503 — превышен лимит запросов к API
  • 504 — сервер не смог обработать ваш запрос за 50 секунд и прервал его выполнение (возможно, вы пытаетесь получить слишком много данных за один запрос)

HTTP GET/POST запрос

Послать GET/POST запрос через HTTP протокол.

Комментарий

При желании, вы можете указать комментарии к данной команде.

Интернет адрес (URL)

Укажите URL адрес куда будет послан запрос.


http://www.mydomain.com/index.php
http://www.mydomain.com/

Type

Метод передачи.
GET — использовать GET метод.
POST — использовать POST метод.
HEAD — использовать HEAD метод.

Поддержка HTTPS протокола
Отметьте этот чекбокс если вы указали https веб-сервер поле Интернет адрес.

Результирующая переменная

Имя переменной, куда будет записан ответ от http-server сервера.

Если вы используйте метод HEAD, то результирующая переменная содержит весь заголовок. Могут быть возвращены следующие результирующие переменные:

Переменные для метода HEAD Описание
[var] Полный заголовок.
[var]_code Код статуса, например (404 или 200).
[var]_ctype Тип, например (text/html).
[var]_size Размер страницы в байтах.
[var]_date Дата последнего изменения, (YYYY.MM.DD.).
[var]_time Время последнего изменения, (HH:MM:SS).

Кодировка UTF-8
Отметьте этот чекбокс, если вебсайт отправляет ответ в кодировке UTF-8.

Условие
Вы можете указать условие при котором необходимо выполнить это действие. Если указанное условие будет ложно, то команда выполняться не будет. Подробнее использование условий описано в Как использовать Условие.


Команда HTTP GET/POST запрос

Параметр

Имя передаваемого параметра.

Значение

Значение передаваемого параметра.

Комментарий
Вы можете добавить в этом поле комментарий.

Quickstart — Запросы 2.25.1 документации

Хотите начать? Эта страница дает хорошее представление о том, как начать работу с запросами.

Сначала убедитесь, что:

Давайте начнем с нескольких простых примеров.

Отправить запрос

Сделать запрос с помощью запросов очень просто.

Начните с импорта модуля запросов:

А теперь попробуем открыть веб-страницу. В этом примере давайте возьмем общедоступный график:

 >>> r = запросы.получить ('https://api.github.com/events')
 

Теперь у нас есть объект Response с именем r . Мы можем получить всю необходимую нам информацию из этого объекта.

Простой API

Requests означает, что все формы HTTP-запросов столь же очевидны. Для Например, вот как вы делаете запрос HTTP POST:

 >>> r = requests.post ('https://httpbin.org/post', data = {'ключ': 'значение'})
 

Красиво, правда? А как насчет других типов HTTP-запросов: PUT, DELETE, HEAD и ПАРАМЕТРЫ? Это все так же просто:

 >>> r = запросы.put ('https://httpbin.org/put', data = {'ключ': 'значение'})
>>> r = requests.delete ('https://httpbin.org/delete')
>>> r = requests.head ('https://httpbin.org/get')
>>> r = requests.options ('https://httpbin.org/get')
 

Это все хорошо, но это только начало того, что запросы могут делать.

Передача параметров в URL-адресах

Вы часто хотите отправить какие-то данные в строке запроса URL. Если вы создавали URL вручную, эти данные будут представлены как ключ / значение пары в URL-адресе после вопросительного знака, e.грамм. httpbin.org/get?key=val . Запросы позволяют вам предоставить эти аргументы в виде словаря строк, используя аргумент ключевого слова params . Например, если вы хотите пройти ключ1 = значение1 и ключ2 = значение2 от до httpbin.org/get , вы должны использовать следующий код:

 >>> payload = {'ключ1': 'значение1', 'ключ2': 'значение2'}
>>> r = requests.get ('https://httpbin.org/get', params = полезная нагрузка)
 

Вы можете увидеть, что URL-адрес был правильно закодирован, напечатав URL-адрес:

 >>> печать (г.URL)
https://httpbin.org/get?key2=value2&key1=value1
 

Обратите внимание, что любой ключ словаря со значением Нет не будет добавлен в Строка запроса URL.

Вы также можете передать список элементов как значение:

 >>> payload = {'ключ1': 'значение1', 'ключ2': ['значение2', 'значение3']}

>>> r = requests.get ('https://httpbin.org/get', params = полезная нагрузка)
>>> печать (r.url)
https://httpbin.org/get?key1=value1&key2=value2&key2=value3
 

Содержание ответа

Мы можем прочитать содержимое ответа сервера.Рассмотрим график GitHub снова:

 >>> запросы на импорт

>>> r = requests.get ('https://api.github.com/events')
>>> r.text
'[{"репозиторий": {"open_issues": 0, "url": "https: //github.com / ...
 

Запросы будут автоматически декодировать контент с сервера. Самый юникод кодировки легко декодируются.

Когда вы делаете запрос, Requests делает обоснованные предположения о кодировке ответ основан на заголовках HTTP. Кодировка текста, угадываемая запросами используется при доступе к р.текст . Вы можете узнать, что такое запросы на кодирование используя, и измените его, используя свойство r.encoding :

 >>> r. Кодирование
'utf-8'
>>> r.encoding = 'ISO-8859-1'
 

Если вы измените кодировку, запросы будут использовать новое значение r.encoding всякий раз, когда вы звоните r.text . Вы можете сделать это в любой ситуации, когда вы можете применить специальную логику, чтобы определить, что кодирование контента будет быть. Например, HTML и XML могут указывать свою кодировку в их тело.В таких ситуациях вы должны использовать r.content , чтобы найти кодирование, а затем установите р. кодирование . Это позволит вам использовать r.text с правильная кодировка.

Запросы также будут использовать пользовательские кодировки, если они вам понадобятся. Если вы создали свою собственную кодировку и зарегистрировали ее с помощью кодеков модуль, вы можете просто использовать имя кодека как значение r.encoding и Запросы будут обрабатывать расшифровку за вас.

Содержимое двоичного ответа

Вы также можете получить доступ к телу ответа в байтах, для нетекстовых запросов:

 >>> г.содержание
b '[{"репозиторий": {"open_issues": 0, "url": "https: //github.com / ...
 

Кодировки передачи gzip и deflate декодируются автоматически.

Например, чтобы создать изображение из двоичных данных, возвращаемых запросом, вы можете используйте следующий код:

 >>> из PIL import Image
>>> из io import BytesIO

>>> i = Image.open (BytesIO (r.content))
 

Содержимое ответа JSON

Существует также встроенный декодер JSON на случай, если вы имеете дело с данными JSON:

 >>> запросы на импорт

>>> r = запросы.получить ('https://api.github.com/events')
>>> r.json ()
[{'репозиторий': {'open_issues': 0, 'url': 'https: //github.com / ...
 

В случае сбоя декодирования JSON r.json () вызывает исключение. Например, если ответ получает 204 (нет содержимого), или, если ответ содержит недопустимый JSON, попытка r.json () вызывает simplejson.JSONDecodeError , если simplejson установлен или вызывает ValueError: объект JSON не может быть декодирован на Python 2 или json.JSONDecodeError на Python 3.

Следует отметить, что успешный вызов r.json () делает , а не указывают на успех ответа. Некоторые серверы могут возвращать объект JSON в неудачный ответ (например, сведения об ошибке с HTTP 500). Такой JSON будет декодирован и вернулся. Чтобы проверить успешность запроса, используйте r.raise_for_status () или проверьте r.status_code — это то, что вы ожидаете.

Необработанное содержимое ответа

В том редком случае, когда вы хотите получить необработанный ответ сокета от сервер, можно получить доступ р.сырье . Если вы хотите это сделать, убедитесь, что вы установили stream = True в вашем первоначальном запросе. Как только вы это сделаете, вы можете сделать это:

 >>> r = requests.get ('https://api.github.com/events', stream = True)

>>> r.raw


>>> r.raw.read (10)
'\ x1f \ x8b \ x08 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x03'
 

В целом, однако, вы должны использовать подобный шаблон, чтобы сохранить то, что передано в файл:

 с open (filename, 'wb') как fd:
    для куска в г.iter_content (chunk_size = 128):
        fd.write (кусок)
 

Использование Response.iter_content будет обрабатывать многое из того, что в противном случае необходимо обрабатывать при использовании Response.raw напрямую. При потоковой передаче загрузки, приведенный выше является предпочтительным и рекомендуемым способом получить содержание. Обратите внимание, что chunk_size можно свободно изменить на число, которое может лучше соответствовать вашим вариантам использования.

Примечание

Важное замечание об использовании Response.iter_content против Response.raw . Response.iter_content автоматически декодирует gzip и deflate передачи-кодировки. Response.raw — это необработанный поток байтов — он не преобразовать содержимое ответа. Если вам действительно нужен доступ к байтам, поскольку они были возвращены, используйте Response.raw .

Более сложные запросы POST

Как правило, вы хотите отправить некоторые закодированные в форме данные — очень похоже на HTML-форму.Для этого просто передайте словарь в аргумент data . Ваш словарь данных будет автоматически закодирован при запросе:

 >>> payload = {'ключ1': 'значение1', 'ключ2': 'значение2'}

>>> r = requests.post ("https://httpbin.org/post", данные = полезная нагрузка)
>>> print (r.text)
{
  ...
  "форма": {
    "ключ2": "значение2",
    «ключ1»: «значение1»
  },
  ...
}
 

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

 >>> payload_tuples = [('ключ1', 'значение1'), ('ключ1', 'значение2')]
>>> r1 = request.post ('https://httpbin.org/post', data = payload_tuples)
>>> payload_dict = {'ключ1': ['значение1', 'значение2']}
>>> r2 = requests.post ('https://httpbin.org/post', данные = payload_dict)
>>> print (r1.текст)
{
  ...
  "форма": {
    "ключ1": [
      "значение1",
      "значение2"
    ]
  },
  ...
}
>>> r1.text == r2.text
Правда
 

Бывают случаи, когда вам может потребоваться отправить данные, не закодированные в форме. Если вы передаете строку вместо dict , эти данные будут опубликованы напрямую.

Например, GitHub API v3 принимает данные POST / PATCH в кодировке JSON:

 >>> импортировать json

>>> url = 'https://api.github.com/some/endpoint'
>>> payload = {'некоторые': 'данные'}

>>> r = запросы.post (url, data = json.dumps (полезная нагрузка))
 

Вместо того, чтобы кодировать dict самостоятельно, вы также можете передать его напрямую, используя параметр json (добавлен в версии 2.4.2), и он будет закодирован автоматически:

 >>> url = 'https://api.github.com/some/endpoint'
>>> payload = {'некоторые': 'данные'}

>>> r = requests.post (url, json = полезная нагрузка)
 

Обратите внимание, что параметр json игнорируется, если передается данных или файлов .

Использование параметра json в запросе изменит Content-Type в заголовке на application / json .

POST файл с многократным кодированием

Requests упрощает загрузку файлов с кодировкой Multipart:

 >>> url = 'https://httpbin.org/post'
>>> files = {'файл': open ('report.xls', 'rb')}

>>> r = requests.post (URL, файлы = файлы)
>>> r.text
{
  ...
  "files": {
    "файл": "<цензура...двоичные ... данные> "
  },
  ...
}
 

Вы можете явно указать имя файла, content_type и заголовки:

 >>> url = 'https://httpbin.org/post'
>>> files = {'file': ('report.xls', open ('report.xls', 'rb'), 'application / vnd.ms-excel', {'Expires': '0'}) }

>>> r = requests.post (URL, файлы = файлы)
>>> r.text
{
  ...
  "files": {
    "файл": "<цензура ... двоичные ... данные>"
  },
  ...
}
 

При желании вы можете отправлять строки для получения в виде файлов:

 >>> url = 'https: // httpbin.org / post '
>>> files = {'file': ('report.csv', 'some, data, to, send \ nanother, row, to, send \ n')}

>>> r = requests.post (URL, файлы = файлы)
>>> r.text
{
  ...
  "files": {
    "файл": "некоторые, данные, отправить \\ другую, строку, кому, отправить \\ n"
  },
  ...
}
 

Если вы публикуете очень большой файл как multipart / form-data запрос, вы можете захотеть передать запрос в потоковом режиме. По умолчанию запросов не выполняет поддерживают это, но есть отдельный пакет, который — запросов-toolbelt .Вам следует прочитать документацию к toolbelt, чтобы узнать больше о том, как его использовать.

Для отправки нескольких файлов в одном запросе см. Расширенный раздел.

Предупреждение

Настоятельно рекомендуется открывать файлы в двоичном формате. режим. Это потому, что запросы могут пытаться предоставить заголовок Content-Length для вас, и если это значение будет установлено количество байтов в файле . Возможны ошибки если открыть файл в текстовом режиме .

Коды состояния ответа

Мы можем проверить код статуса ответа:

 >>> r = requests.get ('https://httpbin.org/get')
>>> r.status_code
200
 

Requests также имеет встроенный объект поиска кода состояния для упрощения Ссылка:

 >>> r.status_code == requests.codes.ok
Правда
 

Если мы сделали неверный запрос (ошибка клиента 4XX или ответ ошибки сервера 5XX), мы можно поднять с Response.raise_for_status () :

 >>> bad_r = запросы.получить ('https://httpbin.org/status/404')
>>> bad_r.status_code
404

>>> bad_r.raise_for_status ()
Отслеживание (последний вызов последний):
  Файл "requests / models.py", строка 832, в файле raise_for_status.
    поднять http_error
request.exceptions.HTTPError: ошибка клиента 404
 

Но, поскольку наш status_code для r был 200 , когда мы звоним raise_for_status () получаем:

 >>> r.raise_for_status ()
Никто
 

Все хорошо.

Файлы cookie

Если ответ содержит файлы cookie, вы можете быстро получить к ним доступ:

 >>> url = 'http://example.com/some/cookie/setting/url'
>>> r = requests.get (URL)

>>> r.cookies ['example_cookie_name']
example_cookie_value
 

Для отправки собственных файлов cookie на сервер вы можете использовать файлы cookie параметр:

 >>> url = 'https://httpbin.org/cookies'
>>> cookies = dict (cookies_are = 'работает')

>>> r = запросы.получить (url, cookies = cookies)
>>> r.text
'{"cookies": {"cookies_are": "рабочие"}}'
 

Cookies возвращаются в RequestsCookieJar , который действует как dict , но также предлагает более полный интерфейс, подходит для использования в нескольких доменах или путях. Банки для печенья могут также передаваться в запросы:

 >>> jar = requests.cookies.RequestsCookieJar ()
>>> jar.set ('вкусное_cookie', 'ням', домен = 'httpbin.org', путь = '/ куки')
>>> баночка.set ('ross_cookie ',' blech ', domain =' httpbin.org ', path =' / elsewhere ')
>>> url = 'https://httpbin.org/cookies'
>>> r = requests.get (URL, файлы cookie = jar)
>>> r.text
'{"печенье": {"вкусное_cookie": "ням"}}'
 

Перенаправление и история

По умолчанию запросы будут выполнять перенаправление местоположения для всех глаголов, кроме ГЛАВА.

Мы можем использовать свойство history объекта Response для отслеживания перенаправления.

Ответ .список history содержит Ответ объектов, которые были созданы для того, чтобы заполните заявку. Список отсортирован от самого старого к самому последнему. отклик.

Например, GitHub перенаправляет все HTTP-запросы на HTTPS:

 >>> r = requests.get ('http://github.com/')

>>> r.url
'https://github.com/'

>>> r.status_code
200

>>> r.history
[<Ответ [301]>]
 

Если вы используете GET, OPTIONS, POST, PUT, PATCH или DELETE, вы можете отключить обработка перенаправления с помощью параметра allow_redirects :

 >>> r = запросы.получить ('http://github.com/', allow_redirects = False)

>>> r.status_code
301

>>> r.history
[]
 

Если вы используете HEAD, вы также можете включить перенаправление:

 >>> r = requests.head ('http://github.com/', allow_redirects = True)

>>> r.url
'https://github.com/'

>>> r.history
[<Ответ [301]>]
 

Таймауты

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

 >>> requests.get ('https://github.com/', тайм-аут = 0,001)
Отслеживание (последний вызов последний):
  Файл "", строка 1, в 
request.exceptions.Timeout: HTTPConnectionPool (host = 'github.com', port = 80): истекло время ожидания запроса. (тайм-аут = 0,001)
 

Примечание

тайм-аут не ограничивает время загрузки всего ответа; скорее, возникает исключение, если сервер не выдал ответ на таймаут секунд (точнее, если байт не было получен на нижележащем сокете за таймаут секунд).Если тайм-аут не указан явно, запросы выполняются. не тайм-аут.

Ошибки и исключения

В случае сетевой проблемы (например, сбой DNS, отказ в соединении и т. Д.), Запросы вызовут исключение ConnectionError .

Response.raise_for_status () будет вызвать HTTPError , если HTTP-запрос вернул неудачный код состояния.

Если время ожидания запроса истекло, возникает исключение Тайм-аут . поднятый.

Если запрос превышает настроенное максимальное количество перенаправлений, TooManyRedirects, исключение.

Все исключения, которые явно вызывают запросы, наследуются от запросов.exceptions.RequestException .


Готовы к большему? Ознакомьтесь с расширенным разделом.

Если вы работаете на рынке труда, подумайте о том, чтобы пройти этот тест по программированию. Если вы найдете работу через эту платформу, этому проекту будет сделано существенное пожертвование.

запросов на строительство | Центр обучения Postman

В Postman можно отправлять запросы на подключение к API, с которыми вы работаете.Ваши запросы могут извлекать, добавлять, удалять и обновлять данные. Если вы создаете или тестируете свой собственный API или интегрируетесь со сторонним API, вы можете опробовать свои запросы в Postman. Ваши запросы могут отправлять параметры, данные авторизации и любые требуемые основные данные.

Например, если вы создаете клиентское приложение (например, мобильное или веб-приложение) для магазина, вы можете отправить один запрос на получение списка доступных продуктов, другой запрос на создание нового заказа (включая сведения о выбранных продуктах. ) и другой запрос на вход клиента в свою учетную запись.

Когда вы отправляете запрос, Postman отображает ответ, полученный от сервера API, таким образом, чтобы вы могли изучить, визуализировать и, при необходимости, устранить неполадки.

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

Содержание

Создание запросов

Ваши запросы могут включать несколько деталей, определяющих данные, которые Postman будет отправлять в API, с которым вы работаете. По крайней мере, вам нужно будет ввести URL-адрес и выбрать метод, но при желании вы можете указать множество других деталей.

Вы можете создать новый запрос на экране запуска Postman, используя Новый > Запрос , или нажав кнопку + , чтобы открыть новую вкладку.

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

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

Добавление детали запроса

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

Если вы просто пытаетесь отправить запросы в Postman, вы можете установить URL-адрес конечной точки API-интерфейса Postman Echo https://postman-echo.com/get и метода GET , затем щелкнуть Отправить чтобы увидеть, что происходит.

Откройте Bootcamp в Postman и следуйте инструкциям Designing and mocking API , чтобы импортировать некоторые запросы, которые вы можете использовать для изучения Postman.Вы найдете гораздо больше примеров коллекций запросов, используя New > Templates .

Настройка URL-адресов запроса

Для каждого запроса, отправляемого в Postman, требуется URL-адрес, представляющий конечную точку API, с которой вы работаете. Каждая операция, которую вы можете выполнить с помощью API, обычно связана с конечной точкой. Каждая конечная точка в API доступна по определенному URL-адресу — это то, что вы вводите в Postman для доступа к API.

  • Если вы создаете API, URL-адрес обычно представляет собой базовое расположение плюс путь.Например, в запросе https://api-test-fun.glitch.me/info , https://api-test-fun.glitch.me — это базовый URL, а / info — путь к конечной точке.
  • Если вы используете сторонний API, ваш поставщик API предоставит вам необходимые URL-адреса, например, в своей документации для разработчиков.

Когда вы начнете вводить поле ввода URL-адреса, Postman представит раскрывающийся список ранее использованных местоположений, которые вы можете использовать для автозаполнения.

Введите https: // почтальон-эхо.com / get , если вы просто хотите опробовать запрос.

Почтальон автоматически добавит http: // в начало вашего URL, если вы не укажете протокол.

При желании вы можете ввести параметры запроса в поле URL или ввести их на вкладке «Параметры». Если в вашем запросе используются параметры path , вы можете ввести их прямо в поле URL.

В запросах можно использовать кодировку URL следующего поколения.

Выбор методов запроса

По умолчанию Почтальон выберет метод GET для нового запроса. GET Методы обычно предназначены для получения данных из API. Вы можете использовать множество других методов для отправки данных вашим API, включая следующие наиболее распространенные варианты:

  • POST —добавить новые данные
  • PUT — заменить существующие данные
  • PATCH — обновление некоторых существующих полей данных
  • DELETE — удалить существующие данные

Например, если вы работаете с API для приложения списка дел, вы можете использовать метод GET для получения текущего списка задач, метод POST для создания новой задачи и метод PUT или PATCH метод для редактирования существующей задачи.

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

Чтобы опробовать конечную точку https://postman-echo.com/get , оставьте выбранным метод GET и нажмите Отправить .

Одно и то же местоположение (иногда называемое «маршрутом») может предоставить более одной конечной точки, принимая разные методы — например, API может иметь конечную точку POST / клиент для добавления нового клиента и GET / клиент конечная точка для поиска существующего клиента.

  • Если ваш запрос не требует параметров или аутентификации, вы можете продолжить и нажать Отправить , чтобы получить ответ.
  • В противном случае укажите свои параметры и любые основные данные, которые необходимо отправить в API.
  • Если вам не нужно отправлять данные с вашим запросом, настройте любую необходимую аутентификацию и заголовки.

Параметры отправки

Вы можете отправлять параметры пути и запроса с вашими запросами, используя поле URL и вкладку Params .

  • Параметры запроса добавляются в конец URL-адреса запроса после ? и перечислен в парах ключ-значение, разделенных и с использованием следующего синтаксиса: ? Id = 1 & type = new
  • Параметры пути образуют часть URL-адреса запроса, и на них ссылаются с помощью заполнителей, которым предшествует : , как в следующем примере: / customer /: id

Чтобы отправить параметр запроса, добавьте его непосредственно в URL-адрес или откройте Params и введите имя и значение. Вы можете ввести параметры запроса в поля URL или UI, и они будут обновлены в другом месте.

Параметры не будут автоматически кодироваться URL-адресом. Щелкните выделенный текст правой кнопкой мыши и выберите EncodeURIComponent , чтобы вручную закодировать значение параметра.

Чтобы отправить параметр пути, введите имя параметра в поле URL-адреса после двоеточия, например : id . Когда вы вводите параметр пути, Postman заполняет его на вкладке Params , где вы также можете его редактировать.

Вы можете добавить описания к своим параметрам, и они будут отображаться для всех, кто разделяет запрос (например, в вашей рабочей области) или просматривает вашу документацию по API.

Вы можете использовать опцию Bulk Edit , если вы предпочитаете вводить параметры в тексте вместо использования пользовательского интерфейса.

Если ваш запрос не требует основных данных, аутентификации или заголовков, нажмите Отправить , чтобы опробовать его. В противном случае настройте тело, аутентификацию и заголовки.

Отправка данных тела

Вам нужно будет отправлять основные данные с запросами всякий раз, когда вам нужно добавить или обновить структурированные данные. Например, если вы отправляете запрос на добавление нового клиента в базу данных, вы можете включить данные клиента в JSON. Обычно вы будете использовать данные тела с запросами PUT , POST и PATCH .

Вкладка Body в Postman позволяет указать данные, которые необходимо отправить с запросом. Вы можете отправлять различные типы данных тела в соответствии с вашим API.

Если вы отправляете основные данные, убедитесь, что у вас выбраны правильные заголовки, чтобы указать тип контента, который может потребоваться вашему API для правильной обработки полученных данных.

  • Для типов тела form-data и urlencoded Postman автоматически присоединит правильный заголовок Content-Type .
  • Если вы используете необработанный режим для данных тела, Postman установит заголовок на основе выбранного вами типа (например, текст, json).
  • Если вы вручную выберете заголовок Content-Type , это значение будет иметь приоритет над тем, что устанавливает Postman.
  • Почтальон не устанавливает тип заголовка для двоичного типа тела.

По умолчанию Почтальон выберет Нет — оставьте его выбранным, если вам не нужно отправлять тело с вашим запросом.

Выберите тип данных, который вам нужен для тела запроса — данные формы, в кодировке URL, необработанные, двоичные или GraphQL.

Данные формы

Формы веб-сайтов часто отправляют данные в API как multipart / form-data . Вы можете воспроизвести это в Postman, используя вкладку form-data Body .Данные формы позволяют отправлять пары ключ-значение и указывать тип содержимого.

Вы можете прикреплять файлы, используя данные формы. Когда вы неоднократно выполняете вызовы API, которые отправляют одни и те же файлы, Postman сохранит ваши пути к файлам для последующего использования. Это также помогает запускать коллекции, содержащие запросы, требующие загрузки файлов. Загрузка нескольких файлов, каждый со своим типом содержимого, пока не поддерживается.

URL-кодирование

Данные в кодировке URL используют ту же кодировку, что и параметры URL.Если вашему API требуются данные в кодировке url, выберите x-www-form-urlencoded на вкладке Body вашего запроса. Введите пары ключ-значение для отправки с запросом, и Почтальон закодирует их перед отправкой.

Иногда возникает путаница между данными формы и кодировкой URL. Если вы не уверены, какой из них вам нужен, обратитесь к своему поставщику API.

Необработанные данные

Вы можете использовать необработанные данные тела для отправки всего, что вы можете ввести в виде текста. Используйте вкладку raw и раскрывающийся список типов, чтобы указать формат ваших данных ( Text , JavaScript , JSON , HTML или XML ), и Postman включит подсветку синтаксиса. а также добавление соответствующих заголовков к вашему запросу.

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

Вы можете использовать переменные в своих данных тела, и Почтальон подставит их текущие значения при отправке вашего запроса.

Выделите текст в редакторе и нажмите CMD / CTRL + B , чтобы украсить ваш XML / JSON.

Двоичные данные

Вы можете использовать двоичные данные для отправки информации, которую вы не можете ввести вручную в редакторе Postman с телом запроса, например изображения, аудио и видео файлы (вы также можете отправлять текстовые файлы).

GraphQL

Вы можете отправлять запросы GraphQL вместе с запросами Postman, выбрав вкладку GraphQL в запросе Body . Введите свой код в область Query и любые переменные в разделе GraphQL Variables .

Ознакомьтесь с разделом Использование GraphQL для получения дополнительной информации о GraphQL, в том числе о том, как включить автозаполнение на основе схем Postman API.

Аутентификационные запросы

Для некоторых API требуются данные аутентификации, которые можно отправить в Postman.Аутентификация включает в себя проверку личности клиента, отправляющего запрос, а авторизация включает проверку того, что у клиента есть разрешение на выполнение операции конечной точки. Откройте вкладку Авторизация , чтобы настроить данные доступа.

Почтальон автоматически включит ваши данные авторизации в соответствующую часть запроса, например, в Заголовки .

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

После настройки авторизации и других деталей запроса вы можете нажать Отправить , чтобы запустить запрос.

Некоторые API-интерфейсы требуют, чтобы вы отправляли определенные заголовки вместе с запросами, как правило, для предоставления дополнительных метаданных о выполняемой вами операции. Вы можете настроить их на вкладке Заголовки . Введите любые пары ключ-значение, которые вам нужны, и Почтальон отправит их вместе с вашим запросом. По мере ввода Postman будет предлагать вам общие параметры, которые можно использовать для автозаполнения настроек, например Content-Type .

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

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

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

Почтальон укажет, почему был добавлен заголовок.

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

Отключение или переопределение рекомендуемых заголовков может привести к неожиданному поведению вашего запроса.

Если вам нужно изменить заголовок, вы можете сделать это в соответствующей части Postman, например, на вкладке Authorization , в запросе Body , Cookies для домена запроса, Settings и в некоторых кейсов прямо в самой вкладке Заголовки .

Если вам нужно перейти в другую часть приложения, Почтальон покажет ссылку справа.

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

Чтобы изменить заголовки файлов cookie, измените настройки файлов cookie для домена, на который вы отправляете запрос.

Чтобы отключить автоматически сгенерированный заголовок непосредственно в Заголовки , снимите соответствующий флажок. Чтобы переопределить автоматически созданное значение заголовка, снимите флажок с автоматически созданной записи и добавьте отдельную запись для заголовка, указав ее имя в поле Key и указав свое значение в поле Value .

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

Для заголовков Content-Length и Content-Type Postman автоматически вычислит значения при отправке запроса на основе данных на вкладке Body .Однако вы можете переопределить оба значения.

После настройки заголовков и других деталей запроса вы можете нажать Отправить , чтобы запустить запрос.

Использование файлов cookie

Вы можете управлять файлами cookie для своих доменов из Postman. Щелкните Cookies под кнопкой Отправить . Для получения дополнительной информации см. Управление файлами cookie.

Выбор пользовательских настроек

Вы можете настроить различные параметры для запросов Postman с помощью вкладки Request Settings .Это позволяет применять нестандартную логику к вашим запросам.

Кодирование URL-адресов вашего запроса

Postman анализирует и кодирует URL-адрес вашего запроса, чтобы максимизировать шансы на успешный вызов API. Почтальон кодирует символы в вашем URL-адресе и сопоставляет их с представлением, которое ваш API, скорее всего, примет. Обработчик URL-адресов Postman оптимизирует вероятность того, что ваш запрос будет эффективно обработан широким спектром используемых серверных реализаций.

Процессор будет кодировать символы в зависимости от того, где они встречаются в URL:

Компонент URL Символов для кодирования
Путь " < > ` # ? { } ПРОСТРАНСТВО
Запрос " # и ' < = > ПРОСТРАНСТВО
Userinfo " < > ` # ? { } / : ; = @ [ \ ] ^ | ПРОСТРАНСТВО

Процессор будет включен по умолчанию в вашем приложении Postman, однако вы можете отключить кодирование, если вы работаете с необычной реализацией сервера.Включите или выключите параметр в своем запросе. Настройки > Кодировать URL автоматически .

Вы можете выборочно кодировать части своего URL-адреса, выделив текст и щелкнув правой кнопкой мыши, а затем выбрав EncodeURIComponent .

Устранение неполадок с вашими запросами

Почтальон укажет любые пробелы / потенциально недопустимые символы в частях вашего запроса, которые могут не работать должным образом, чтобы вы могли исправить свои значения.Вы увидите выделенные символы в методе запроса, URL-адресе (включая путь), параметрах, заголовках (включая имена ваших ключей) и теле.

Если Почтальон не может отправить ваш запрос или не получает ответа, вы увидите подробную информацию об ошибке.

Щелкните Просмотр в консоли , чтобы просмотреть обзор вашего запроса и определить источник проблемы.

Если ваш запрос не работает должным образом, ознакомьтесь с некоторыми советами по устранению неполадок.

Следующие шаги

После настройки запроса нажмите Отправить и изучите ответ.

Объекты запроса и ответа | Документация Django

Передающие строки¶

Типичное использование - передача содержимого страницы в виде строки, строки байтов, или memoryview , в конструктор HttpResponse :

 >>> из django.http import HttpResponse
>>> response = HttpResponse ("Вот текст веб-страницы.")
>>> response = HttpResponse ("Только текст, пожалуйста.", content_type = "text / plain")
>>> response = HttpResponse (также принимаются строки b'Bytestrings. ')
>>> response = HttpResponse (memoryview (также b'Memoryview. '))
 

Но если вы хотите добавлять контент постепенно, вы можете использовать ответ как файловый объект:

 >>> ответ = HttpResponse ()
>>> response.write ("

Вот текст веб-страницы.

") >>> ответ.write ("

Вот еще один абзац

")
Передача итераторов¶

Наконец, вы можете передать HttpResponse итератор, а не строки. HttpResponse немедленно использует итератор, сохраняя его содержимое как строка и отбросьте ее. Объекты с методом close () , такие как файлы и генераторы сразу закрываются.

Если вам нужно, чтобы ответ передавался от итератора к клиенту, вы вместо этого необходимо использовать класс StreamingHttpResponse .

Настройка полей заголовка¶

Чтобы установить или удалить поле заголовка в своем ответе, используйте HttpResponse.headers :

 >>> ответ = HttpResponse ()
>>> response.headers ['Возраст'] = 120
>>> del response.headers ['Возраст']
 

Вы также можете управлять заголовками, рассматривая свой ответ как словарь:

 >>> ответ = HttpResponse ()
>>> response ['Возраст'] = 120
>>> del response ['Возраст']
 

Это прокси на HttpResponse.заголовки , и это оригинальный интерфейс, предлагаемый автор: HttpResponse .

При использовании этого интерфейса, в отличие от словаря, del не вызывает KeyError , если поле заголовка не существует.

Вы также можете установить заголовки при создании экземпляра:

 >>> response = HttpResponse (заголовки = {'Возраст': 120})
 

Для настройки полей заголовка Cache-Control и Vary рекомендуется использовать patch_cache_control () и patch_vary_headers () методов из джанго.utils.cache , так как эти поля могут иметь несколько разделенных запятыми значения. Методы «patch» гарантируют, что другие значения, например добавлено промежуточное ПО, не удаляются.

Поля заголовка HTTP не могут содержать символы новой строки. Попытка установить поле заголовка содержащий символ новой строки (CR или LF) вызовет BadHeaderError

Изменено в Django 3.2:

Добавлен интерфейс HttpResponse.headers .

Добавлена ​​возможность задавать заголовки при инстанциации.

Указание браузеру рассматривать ответ как вложение файла¶

Чтобы браузер обрабатывал ответ как вложение файла, установите Content-Type и Content-Disposition заголовков. Например, вот как вы можете вернуть электронную таблицу Microsoft Excel:

 >>> response = HttpResponse (my_data, headers = {
... 'Content-Type': 'application / vnd.ms-excel',
... 'Content-Disposition': 'attachment; filename = "foo.xls" ',
...})
 

В заголовке Content-Disposition нет ничего специфичного для Django, но синтаксис легко забыть, поэтому мы включили его сюда.

xdmp: get-request-body - Документация по продукту MarkLogic 10

 xdmp: get-request-body (
   [$ форматировать как xs: string?]
) как элемент () * 

Сводка

Для запросов PUT или DELETE возвращает тело запроса. Для запросов POST возвращает тело запроса, если оно не приложение типа содержимого / x-www-form-urlencoded.

Возвращает пустую последовательность, если она не вызывается из приложения. сервер.

Параметры
$ формат Формат («xml», «json», «текст» или «двоичный») для интерпретации тела как. Если не указан, формат, связанный с заголовком типа содержимого в mimetypes.xml используется. Если нет Заголовок типа содержимого существует, формат по умолчанию - "двоичный".

Примечания по использованию

Если тип содержимого тела POST - application / x-www-form-urlencoded, он недоступен здесь, но вместо этого доступен в его декодированной форме через xdmp: get-request-field-names () и xdmp: получить поле запроса () .

Если в запросе нет заголовка типа содержимого, то запрос тело по умолчанию имеет значение application / x-www-form-urlencoded, и поэтому xdmp: get-request-body вернет пустую последовательность. Если вы хотите прочитать тело запроса, тогда POST должен включать заголовок типа содержимого.

Вы можете использовать эту функцию для обработки определенных типов веб-служб. Запросы SOAP с сервером MarkLogic.

Результатом вызова xdmp: get-request-body является обычно это узел документа, поэтому, если вы хотите получить содержимое POST, вы должны добавить шаг / node () XPath в выход.Содержимое узла документа может быть текстовым узлом, узел элемента или двоичный узел.

Пример

xdmp: получить тело запроса () / узел ()
=> " Содержимое тела сообщения. "
 

Как использовать модуль запросов Python с API REST

Узнайте, как использовать модуль Python Requests для взаимодействия с любым REST API в мире.

Бен Ллойд Пирсон | 11 июня 2020 г.

Ясный и простой синтаксис Python делает его идеальным языком для взаимодействия с REST API, и, в типичном для Python стиле, существует библиотека, созданная специально для обеспечения этой функциональности: запросы.Python Requests - это мощный инструмент, который обеспечивает простую элегантность Python для выполнения HTTP-запросов к любому API в мире. В Nylas мы создали наши REST API для электронной почты, календаря и контактов на Python, и мы обрабатываем более 500 миллионов запросов API в день, поэтому, естественно, мы сильно зависим от библиотеки Python Requests.

В этом руководстве мы подробно рассмотрим создание HTTP-запросов с помощью запросов Python и узнаем, как использовать эту функцию для интеграции с REST API.

Хотите PDF-файл этой статьи?

Поделитесь им с другом или сохраните для последующего чтения.

В комплекте:

Роли HTTP, API и REST

Интерфейс прикладного программирования (API) - это веб-служба, которая предоставляет доступ к определенным данным и методам, к которым другие приложения могут получать доступ - а иногда и редактировать - через стандартные протоколы HTTP, как веб-сайт. Эта простота позволяет легко и быстро интегрировать API-интерфейсы в самые разные приложения. REpresentational State Transfer (REST), вероятно, самый популярный архитектурный стиль API для веб-сервисов.Он состоит из набора руководящих принципов, предназначенных для упрощения взаимодействия клиент / сервер. API-интерфейсы REST делают доступ к данным более простым и логичным.

Запрос

Если вы хотите взаимодействовать с данными через REST API, это называется запросом. Запрос состоит из следующих компонентов:

Конечная точка - URL-адрес, определяющий, с какими данными вы взаимодействуете. Подобно тому, как URL-адрес веб-страницы привязан к определенной странице, URL-адрес конечной точки привязан к определенному ресурсу в API.

Метод - определяет, как вы взаимодействуете с ресурсом, находящимся в указанной конечной точке. API-интерфейсы REST могут предоставлять методы для включения всех функций создания, чтения, обновления и удаления (CRUD). Вот общие методы, которые предоставляет большинство REST API:

  • GET - Получить данные
  • PUT - заменить данные
  • POST - Создание данных
  • DELETE - Удалить данные

Data - Если вы используете метод, который включает изменение данных в REST API, вам нужно будет включить полезную нагрузку данных в запрос, который включает все данные, которые будут созданы или изменены.

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

Ответ

Когда вы выполняете запрос, вы получаете ответ от API. Как и в запросе, у него будет заголовок ответа и данные ответа, если применимо. Заголовок ответа состоит из полезных метаданных об ответе, а данные ответа возвращают то, что вы действительно запросили.Это могут быть данные любого типа, поскольку они действительно зависят от API. Текст обычно возвращается как JSON, но также возможны другие языки разметки, такие как XML.

Давайте посмотрим на простой пример запроса и ответа. В терминале мы будем использовать curl, чтобы сделать GET-запрос к Open Notify API. Это простой, но изящный API, который содержит информацию об астронавтах, которые в настоящее время находятся в космосе:

 curl -X GET "http://api.open-notify.org/astros.json"
 
Вы должны увидеть ответ в формате JSON, в котором перечислены данные об этих астронавтах, на момент написания этой статьи три человека совершили историческое путешествие на Международную космическую станцию:
 {
  «число»: 3,
  "message": "успех",
  "люди": [
    {
      "craft": "МКС",
      "name": "Крис Кэссиди"
    },
    {
      "craft": "МКС",
      "name": "Анатолий Иванишин"
    },
    {
      "craft": "МКС",
      "name": "Иван Вагнер"
    }
  ]
}
 

Как использовать запросы Python с REST API

Теперь давайте посмотрим, что нужно для интеграции с REST API с использованием запросов Python.Во-первых, вам понадобится необходимое программное обеспечение; убедитесь, что на вашем компьютере установлены Python и pip. Затем перейдите в командную строку и установите модуль запросов Python с помощью pip:

 запросов на установку пипса
 

Теперь вы готовы начать использовать запросы Python для взаимодействия с REST API. Убедитесь, что вы импортировали библиотеку запросов во все сценарии, в которых хотите ее использовать:

 запросов на импорт
 

Как запросить данные с помощью GET

Метод GET используется для доступа к данным для определенного ресурса из REST API; Python Requests включает функцию для этого.

 запросов на импорт
response = requests.get ("http://api.open-notify.org/astros.json")
печать (ответ)
>>>> Ответ <200> 

Объект ответа содержит все данные, отправленные с сервера в ответ на ваш запрос GET, включая заголовки и полезные данные. Когда этот пример кода выводит объект ответа на консоль, он просто возвращает имя класса объекта и код состояния, возвращенный запросом (подробнее о кодах состояния позже).

Хотя эта информация может быть полезной, вас, скорее всего, интересует содержание самого запроса, к которому можно получить доступ несколькими способами:

 ответ.content () # Возвращает необработанные байты полезной нагрузки данных
response.text () # Возвращает строковое представление полезных данных
response.json () # Этот метод удобен, когда API возвращает JSON 

Как использовать параметры запроса

Запросы можно использовать для фильтрации данных, возвращаемых API, и они добавляются как параметры запроса, которые добавляются к URL-адресу конечной точки. В запросах Python это обрабатывается с помощью аргумента params, который принимает объект словаря; давайте посмотрим, как это будет выглядеть, когда мы используем Open Notify API, чтобы ПОЛУЧИТЬ оценку того, когда МКС пролетит над указанной точкой:

 query = {'широта': '45', 'долгота': '180'}
ответ = запросы.получить ('http://api.open-notify.org/iss-pass.json', params = query)
печать (response.json ()) 

Команда печати вернет что-то вроде этого:

 {
  'сообщение': 'успех',
  'запрос': {
    'высота': 100,
    'datetime': 15799,
    'широта': 45,0,
    'долгота': 180,0,
    'проходов': 5
  },
  'отклик': [
    {'duration': 307, 'risetime': 15341},
    {'duration': 627, 'risetime': 15934},
    {'duration': 649, 'risetime': 15
  • 725}, {'duration': 624, 'risetime': 15
  • 575}, {'duration': 643, 'risetime': 15408} ] }
  • Как создавать и изменять данные с помощью POST и PUT

    Аналогично параметрам запроса вы можете использовать аргумент данных для добавления связанных данных для запросов методов PUT и POST.

     # Создать новый ресурс
    response = requests.post ('https://httpbin.org/post', data = {'ключ': 'значение'})
    
    # Обновить существующий ресурс
    request.put ('https://httpbin.org/put', data = {'ключ': 'значение'})
    
     

    Как получить доступ к заголовкам REST

    Вы также можете получить метаданные из ответа через заголовки. Например, чтобы просмотреть дату ответа, просто укажите это в свойстве `headers`:

     печать (response.headers ["дата"])
    >>>> 'Ср, 11 июня 2020 19:32:24 GMT' 

    Для открытых API, который охватывает основы.Однако многие API не могут использоваться кем-либо. Для них давайте рассмотрим, как аутентифицироваться в REST API.

    Как пройти аутентификацию в REST API

    До сих пор вы видели, как взаимодействовать с открытыми API-интерфейсами REST, не требующими авторизации. Однако многие REST API требуют, чтобы вы прошли аутентификацию, прежде чем вы сможете получить доступ к определенным конечным точкам, особенно если они имеют дело с конфиденциальными данными.

    Существует несколько распространенных методов аутентификации для REST API, которые можно обрабатывать с помощью запросов Python.Самый простой способ - передать ваше имя пользователя и пароль в соответствующую конечную точку как HTTP Basic Auth; это эквивалентно вводу вашего имени пользователя и пароля на веб-сайте.

     requests.get (
      'https://api.github.com/user',
      auth = HTTPBasicAuth ('имя пользователя', 'пароль')
    ) 

    Более безопасный метод - получить токен доступа, который действует как эквивалент комбинации имени пользователя и пароля; метод получения токена доступа сильно различается от API к API, но наиболее распространенной структурой для аутентификации API является OAuth.Здесь, в Nylas, мы используем трехсторонний протокол OAuth для предоставления токена доступа для учетных записей пользователей, который ограничен областями, определяющими конкретные данные и функции, к которым можно получить доступ. Этот процесс демонстрируется в службе Nylas Hosted Auth.

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

     my_headers = {'Authorization': 'Bearer {access_token}'}
    ответ = запросы.получить ('http://httpbin.org/headers', headers = my_headers) 

    Существует довольно много других методов аутентификации в REST API, включая дайджест, Kerberos, NTLM и AuthBase. Их использование зависит от архитектурных решений производителя REST API.

    Использование сеансов для управления токенами доступа

    Объекты сеанса пригодятся при работе с запросами Python в качестве инструмента для сохранения параметров, необходимых для выполнения нескольких запросов в рамках одного сеанса, например токенов доступа.Кроме того, управление файлами cookie сеанса может обеспечить хороший рост производительности, поскольку вам не нужно открывать новое соединение для каждого запроса.

     сеанс = запросы.Session ()
    session.headers.update ({'Авторизация': 'Носитель {access_token}'})
    response = session.get ('https://httpbin.org/headers') 

    Как обрабатывать ошибки HTTP с помощью запросов Python

    Вызовы

    API не всегда идут по плану, и существует множество причин, по которым запросы API могут завершаться неудачно, которые могут быть ошибкой либо сервера, либо клиента.Если вы собираетесь использовать REST API, вам нужно понимать, как обрабатывать ошибки, которые они выводят, когда что-то идет не так, чтобы сделать ваш код более надежным. В этом разделе описывается все, что вам нужно знать об обработке ошибок HTTP с помощью запросов Python.

    Основы кодов состояния HTTP

    Прежде чем мы углубимся в специфику запросов Python, нам сначала нужно сделать шаг назад и понять, что такое коды состояния HTTP и как они связаны с ошибками, с которыми вы можете столкнуться.

    Все коды состояния попадают в одну из пяти категорий.

    • 1xx Информационный - Указывает, что запрос был получен и что клиент должен продолжать делать запросы полезной нагрузки данных. Скорее всего, вам не нужно будет беспокоиться об этих кодах состояния при работе с запросами Python.
    • 2xx Successful - Указывает, что запрошенное действие было получено, понято и принято. Вы можете использовать эти коды, чтобы проверить наличие данных, прежде чем пытаться с ними работать.
    • 3xx Redirection - указывает, что клиент должен выполнить дополнительное действие для выполнения запроса, например, получить доступ к ресурсу через прокси-сервер или другую конечную точку.Возможно, вам потребуется сделать дополнительные запросы или изменить свои запросы для работы с этими кодами.
    • 4xx Ошибка клиента - указывает на проблемы с клиентом, такие как отсутствие авторизации, запрещенный доступ, запрещенные методы или попытки доступа к несуществующим ресурсам. Обычно это указывает на ошибки конфигурации в клиентском приложении.
    • 5xx Ошибка сервера - указывает на проблемы с сервером, который предоставляет API. Существует большое количество разнообразных ошибок сервера, и для их устранения часто требуется поставщик API.

    Как проверить ошибки HTTP с помощью запросов Python

    Объекты ответа имеют атрибут status_code, который можно использовать для проверки любых ошибок, о которых мог сообщить API. В следующем примере показано, как использовать этот атрибут для проверки успешных и не найденных кодов состояния HTTP 404, и вы можете использовать этот же формат для всех кодов состояния HTTP.

     response = requests.get ("http://api.open-notify.org/astros.json")
    если (response.status_code == 200):
        print («Запрос был успешным!»)
        # Код здесь будет запущен, только если запрос будет успешным
    Элиф (ответ.status_code == 404:
        print («Результат не найден!»)
        # Код здесь будет реагировать на неудачные запросы 

    Чтобы увидеть это в действии, попробуйте удалить последнюю букву из конечной точки URL, API должен вернуть код состояния 404.

    Если вы хотите, чтобы запросы вызывали исключение для всех кодов ошибок (4xx и 5xx), вы можете использовать функцию raise_for_status () и перехватывать определенные ошибки с помощью встроенных исключений запросов. В следующем примере выполняется то же самое, что и в предыдущем примере кода.

     попробуйте:
        ответ = запросы.получить ('http://api.open-notify.org/astros.json')
        response.raise_for_status ()
        # Дополнительный код будет запущен только в том случае, если запрос будет успешным
    кроме requests.exceptions.HTTPError как ошибки:
        печать (ошибка)
        # Этот код будет запущен, если есть ошибка 404. 

    TooManyRedirects

    Коды состояния HTTP 3xx часто указывают на необходимость перенаправления в другое место для ресурса, который вы запрашиваете. Иногда это может привести к возникновению бесконечного цикла перенаправления.В модуле Python Requests есть ошибка TooManyRedirects, которую можно использовать для решения этой проблемы. Чтобы решить эту проблему, вероятно, URL, который вы используете для доступа к ресурсу, неправильный и его необходимо изменить.

     попробуйте:
        response = requests.get ('http://api.open-notify.org/astros.json')
        response.raise_for_status ()
        # Код здесь будет запущен, только если запрос будет успешным
    кроме request.exceptions.TooManyRedirects как error:
        печать (ошибка) 

    Вы можете дополнительно использовать параметры запроса, чтобы установить максимальное количество перенаправлений:

     ответ = запросы.получить ('http://api.open-notify.org/astros.json', max_redirects = 2) 

    Или полностью отключите перенаправление в параметрах вашего запроса:

     response = requests.get ('http://api.open-notify.org/astros.json', allow_redirects = False)
     

    Ошибка подключения

    До сих пор мы рассматривали только ошибки, исходящие от активного сервера. Что произойдет, если вы вообще не получите ответа от сервера? Ошибки подключения могут возникать по разным причинам, включая сбой DNS, отказ в подключении, проблемы с подключением к Интернету или задержку где-то в сети.Python Requests предлагает исключение ConnectionError, которое указывает, когда ваш клиент не может подключиться к серверу.

     попробуйте:
        response = requests.get ('http://api.open-notify.org/astros.json')
        # Код здесь будет запущен, только если запрос будет успешным
    кроме requests.ConnectionError как ошибки:
        печать (ошибка) 

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

    Тайм-аут

    Ошибки тайм-аута возникают, когда вы можете подключиться к серверу API, но он не выполняет запрос в отведенное время. Подобно другим рассмотренным нами ошибкам, запросы Python могут обрабатывать эту ошибку с исключением тайм-аута:

    .
     попробуйте:
        response = requests.get ('http://api.open-notify.org/astros.json', тайм-аут = 0,00001)
        # Код здесь будет запущен, только если запрос будет успешным
    кроме request.Timeout как ошибка:
        печать (ошибка) 

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

    Как сделать надежные запросы API

    Как мы видели, модуль Requests элегантно обрабатывает распространенные ошибки запросов API, используя обработку исключений в Python.Если мы объединим все ошибки, о которых мы говорили, у нас будет довольно простой способ обработать любую ошибку HTTP-запроса, которая встречается на нашем пути:

     попробуйте:
        response = requests.get ('http://api.open-notify.org/astros.json', тайм-аут = 5)
        response.raise_for_status ()
        # Код здесь будет запущен, только если запрос будет успешным
    кроме request.exceptions.HTTPError как errh:
        печать (э-э)
    кроме request.exceptions.ConnectionError как errc:
        печать (ошибка)
    кроме request.exceptions.Timeout как errt:
        печать (ошибка)
    кроме запросов.exceptions.RequestException как ошибка:
        печать (ошибка) 

    Поздравляю, если вы зашли так далеко! Вы на пути к тому, чтобы стать мастером запросов Python, для которого ни один REST API не подходит. Хотите продолжать учиться? У нас, в Nylas, есть масса знающих экспертов по Python, и в нашем блоге есть подробный контент, посвященный упаковке и развертыванию кода Python в производственной среде, а также использованию переменных среды для повышения безопасности вашего кода Python.

    HTTP-запрос - что это? Различные методы и структура HTTP-запросов

    В предыдущей статье мы уже видели, что такое архитектура клиент-сервер и как она работает с использованием протокола связи HTTP.Более того, мы знаем, что HTTP (протокол передачи гипертекста) - это протокол связи TCP / IP , используемый для обмена данными в Интернете. Впоследствии, теперь мы узнаем больше о H TTP Request, , который является одной из основных единиц, используемых в тестировании API. Следовательно, в этой статье мы рассмотрим следующие моменты:

    • Что такое HTTP-запрос?
      • Какие существуют методы HTTP-запроса?
      • И какова структура HTTP-запроса?
    • GET vs.Метод POST

    Что такое HTTP-запрос?

    Как уже было понято в модели клиентской архитектуры, клиент отправляет запрос на сервер для получения некоторой информации или данных. Кроме того, запрос клиента - это HTTP-запрос, который обменивается данными между клиентом и сервером, или, можно сказать, двумя разными компьютерными системами. Более того, это простой текстовый файл в формате XML или JSON, , который отправляет двоичные данные клиента на сервер.Простой HTTP-запрос GET выглядит так:

    Более того, URI запроса в этом случае -

    https://bookstore.toolsqa.com/BookStore/v1/Books

    Какие существуют методы HTTP-запроса?

    Методы HTTP-запроса определяют действие, выполняемое с помощью запроса. Они также известны как глаголы и обычно используются для операций CRUD , т.е.е., создавать, читать, обновлять и удалять. Более того, методы HTTP-запроса чувствительны к регистру и всегда должны быть прописными. Затем давайте посмотрим на некоторые часто используемые HTTP-методы:

    1. GET - Как следует из названия, метод Get получает информацию с сервера. Более того, это наиболее часто используемый метод, не имеющий тела запроса. Каждый раз, когда вы открываете веб-сайт, срабатывает запрос Get для получения содержимого веб-сайта. Кроме того, это эквивалентно операции чтения.Некоторые из основных особенностей метода GET:

    • Мы можем легко добавить данные в закладки, используя метод GET.
    • Предел длины значений обычно составляет 255 символов для метода GET.
    • GET поддерживает только строковые типы данных.
    • GET-запросы кэшируются.
    • Параметры, переданные в методах GET, сохраняются в истории браузера.

    Пример запроса GET будет выглядеть так -

    GET https: // bookstore.toolsqa.com/BookStore/v1/Books HTTP / 1.1

    2. HEAD: Метод Head похож на метод Get, но извлекает только данные заголовка, а не весь текст ответа. Более того, мы используем его, когда вам нужно проверить размер файла документа, не загружая документ.

    3. POST: Метод Post работает для отправки данных на сервер. Вы можете добавлять или обновлять данные, используя почтовый запрос. Мы отправляем информацию, которую необходимо обновить в теле запроса.В реальном мире данные формы обновляются на сайте с помощью запроса Post. Некоторые из важнейших функций метода POST:

    • Данные, передаваемые с помощью метода POST, не отображаются в URL-адресе браузера.
    • Кроме того, значения, переданные через POST, не сохраняются в истории браузера.
    • Более того, нет ограничений на длину данных, отправляемых с помощью метода POST.
    • Кроме того, запрос метода POST поддерживает различные типы данных, такие как String, двоичные, целые числа и т. Д.

    4. PUT: Метод Put аналогичен методу Post, поскольку он обновляет данные. Единственная разница в том, что мы используем его, когда нам нужно полностью заменить существующий объект. Кроме того, методы PUT являются идемпотентными, то есть при повторном выполнении они возвращают один и тот же результат.

    5. PATCH: Этот метод снова похож на методы Post и Put, но мы используем его, когда нам нужно частично обновить некоторые данные. Более того, в отличие от методов Post и Put, вы можете отправлять только ту сущность, которая нуждается в обновлении, в теле запроса с помощью метода Patch.

    6. DELETE: Как и его название, метод Delete удаляет серверные представления ресурсов через определенный URL. Кроме того, как и у метода Get, у них нет тела запроса.

    7. ОПЦИИ: Этот метод не является широко используемым по сравнению с другими. Он возвращает данные, определяющие различные методы и операции, поддерживаемые сервером по данному URL-адресу. Более того, он отвечает заголовком Allow, в котором содержится список HTTP-методов, разрешенных для ресурса.

    Давайте теперь посмотрим, как выглядит структура простого HTTP-запроса.

    Какова структура HTTP-запроса?

    Следующий шаг - понять, как выглядит HTTP-запрос и как он структурирован. HTTP-запрос состоит из-

    1. Строка запроса
    2. Ноль или более заголовков
    3. Необязательное тело запроса

    Давайте теперь посмотрим, что это за компоненты, но перед этим давайте посмотрим на простой BookStore REST API разработан ToolsQA.

    • URL-адрес ресурса: https://bookstore.toolsqa.com/
    • Параметр: BookStore / v1 / Books

    При объединении двух вышеуказанных частей наш URL-адрес запроса становится -

    https://bookstore.toolsqa.com/BookStore/v1/Books

    Теперь вам нужно открыть окно браузера и нажать на этот URL. Впоследствии вы можете открыть инструменты разработчика браузера и перейти на вкладку «Сеть», как показано на изображении ниже, прежде чем перейти по URL-адресу.

    После того, как вы нажмете URL, вы увидите, что отправляются некоторые запросы; вам нужно щелкнуть по первому из них, выделенному ниже, и увидеть, что подробное описание запроса отображается справа.

    Наконец, теперь мы готовы понять различные компоненты HTTP-запроса.

    Строка запроса

    Строка запроса - это самая первая строка в HTTP-запросе.Сочетание трех частей образует его. Строка для нашего случая будет выглядеть так:

    GET / BookStore / v1 / Books HTTP / 1.1

    GET / BookStore / v1 / Books HTTP / 1.1

    Метод HTTP

    Как указано выше, метод HTTP действие, которое должно выполняться через запрос.Более того, наиболее распространенные методы, с которыми вы можете столкнуться, - это GET или POST. Впоследствии мы увидим разницу между ними позже в этом посте.

    URI запроса

    URI запроса, то есть унифицированный идентификатор ресурса, помогает идентифицировать ресурсы, к которым применяется запрос. URI запроса имеет общий формат, как показано ниже.

    Request-URI = "*" | absoluteURI | abs_path | полномочия

    Request-URI = "*" | absoluteURI | abs_path | Authority

    Давайте посмотрим на несколько примеров того, как можно использовать указанный выше URI запроса.

    1. Когда мы используем звездочку «*», это означает, что запрос идет непосредственно на сервер, а не на конкретный ресурс. Кроме того, мы должны использовать его, когда метод в запросе не применяется к ресурсу. Например,
      ОПЦИИ * HTTP / 1.1
    2. Кроме того, форма abosulteURI является обязательной, когда мы делаем запрос к прокси-серверу, который перенаправляет запрос в действительный кеш и возвращает ответ. Более того, абсолютный путь не может быть пустым.Если ничего не присутствует, в URI следует указать «/» (корень сервера). Пример:
      GET https://www.toolsqa.com/ HTTP / 1.1
    3. Более того, наиболее распространенной формой Request-URI является та, которую мы использовали в нашем примере. Клиент получает ресурс непосредственно с исходного сервера, создавая TCP-соединение с портом 80 хоста « bookstore.toolsqa.com, », , и ниже, строки отправляются в запросе-
      GET / BookStore / v1 / Книги HTTP / 1.1

      Хост: bookstore.toolsqa.com

    Версия протокола HTTP

    Версия протокола HTTP позволяет отправителю указывать формат сообщения, а также его способность понимать дальнейшие сообщения. Кроме того, HTTP / 1.1 - это стандартная версия протокола, которую мы обычно используем.

    Заголовок запроса

    Используя заголовок запроса, клиент может отправить дополнительную информацию серверу о запросе, а также о самом клиенте.Кроме того, в запросе может быть ноль или более заголовков, которые могут определять тип контента, спецификацию авторизации, информацию о файлах cookie и т. Д. Кроме того, мы также можем определить настраиваемые заголовки, используя x-синтаксис в соответствии с требованиями. На снимке ниже показаны различные заголовки HTTP-запроса, который мы используем в качестве примера. Кроме того, строка запроса также выделяется.

    В приведенном выше запросе есть несколько полей заголовков, с которыми вы довольно часто будете сталкиваться при тестировании API.Следовательно, давайте быстро взглянем на них -

    • User-Agent: позволяет серверу идентифицировать приложение, операционную систему, поставщика и версию.
    • Подключение: управляет сетевым подключением. Другими словами, убить или продолжить соединение после транзакции.
    • Cache-Control: определяет политики кэширования браузера.
    • Accept-Language: указывает все языки (естественные), которые может понять клиент.

    Помимо указанных выше, некоторые из общих полей заголовка запроса, используемых в соответствии с требованием:

    • Accept-Charset
    • Accept-Encoding
    • Authorization
    • Content-Length
    • Content-Type
    • Cookie
    • Expect
    • From
    • Host
    • If-Match
    • If-Match
    • If-Match -Match
    • If-Range
    • If-Unmodified-Since
    • Max-Forwards
    • Прокси-авторизация
    • Range
    • 25
    • 25

      Тело запроса

      Тело запроса отправляет addit Дополнительная информация на сервер для правильного извлечения данных из запроса.В нашем примере мы не отправляли тело запроса после заголовка запроса, как показано на снимке выше. Кроме того, тело запроса может быть в форме XML или JSON. Впоследствии в следующих статьях мы увидим эти запросы более подробно.

      Сравнение методов GET и POST

      Различие между методами GET и POST является наиболее частым вопросом во время собеседований. Давайте посмотрим на некоторые основные моменты, которые отличают оба этих метода.

      GET POST
      Данные проходят через заголовок Данные проходят через тело запроса
      Размер данных ограничен до 9088 ограничение на размер данных
      Поскольку данные проходят через URL-адрес, они становятся небезопасными Данные защищены, поскольку они не открыты
      Запросы GET ждут ответа на предыдущий запрос перед отправкой следующего запроса Запрос POST не ожидает успешного ответа от предыдущего запроса перед тем, как выполнить следующий.
      Может кэшироваться Не может кэшироваться.
      Можно добавить в закладки Невозможно добавить в закладки.
      Лучшая производительность по сравнению с POST, поскольку значения добавляются к URL-адресу по умолчанию Менее эффективна по производительности по сравнению с GET, поскольку мы тратим некоторое время на включение значений тела запроса в запрос POST
      Only string тип данных разрешен Нет ограничений на тип данных
      Параметры сохраняются в истории браузера Параметры не сохраняются в истории браузера
      Не влияет на данные, если мы нажимаем кнопку перезагрузки. Данные формы сбрасываются, если мы нажимаем кнопку перезагрузки.
      Использует кодировку application / x-www-form-urlencoded Использует application / x-www-form-urlencoded или multipart / form-data для двоичных данных

      Ключевые выводы

      09

          Запросы HTTP отправляют на сервер запросы на получение желаемой информации.
        • Более того, мы увидели разные методы запроса и какие у них есть полезности.
        • Кроме того, мы увидели, как выглядит структура HTTP-запроса и каковы различные компоненты.
        • Более того, запрос GET или DELETE не требует тела запроса.
        • Далее, в нашей следующей статье, мы обсудим HTTP-ответы.

        Отправка запроса GET в REST API | REST API Guide

        Для команды rpc общий формат конечных точек:

        схема: // имя-устройства: порт / rpc / method [@attributes] / params

        • схема : http или https

        • метод : Имя любого Юноса Команда OS rpc .Имя метода идентично элементу тега. Для получения дополнительной информации см. Справочное руководство разработчика Junos XML API .

        • params : необязательный параметр значения ( имя [= значение] ).

        Чтобы подтвердить свой запрос, отправьте имя пользователя в кодировке base64 и пароль, указанный в заголовке авторизации:

          curl -u "имя пользователя: пароль" http: // имя-устройства: порт / rpc / get-interface-information  

        Чтобы указать данные rpc в виде строки запроса в URI для запросов GET можно использовать ? после URI с разделителем и разделяя несколько аргументов, или используйте разделитель /, как показано в этих эквивалентных вызовах cURL:

        Например:

          curl -u "имя пользователя: пароль" http: // имя-устройства: порт / rpc / get-interface-information? Interface-name = cbp0 & snmp-index = 1 
          curl -u "имя пользователя: пароль" http: // имя-устройства: порт / rpc / get-interface-information / interface-name = cbp0 / snmp-index = 1  

        Заголовки HTTP Accept могут использоваться для указания формат возврата используя одно из следующих значений Content-Type:

        Например, следующий вызов cURL определяет выходной формат из JSON:

         curl -u "имя пользователя: пароль" http: // имя-устройства: порт / rpc / get-interface-information? Interface-name = cbp0 –header "Accept: application / json"
         

        Вы также можете указать выходной формат, используя необязательный параметр format .

        Например, элемент тега извлекает уровни редакции программного процесса. Следующие Запрос HTTPS GET выполняет эту команду и получает результаты в формате JSON:

         https: // имя-устройства: 3000 / rpc / get-software-information @ format = json 

        Следующая программа Python использует интерфейс REST для выполнения get-route-engine-information RPC, извлекает данные из ответа, и строит график средней загрузки процессора:

         импортировать numpy как np
        import matplotlib.pyplot как plt
        импортировать matplotlib.animation как анимацию
        запросы на импорт
        
        temp_y = 1
        def update_line (число, данные, строка):
            если num == 0:
        обратная линия,
            global temp_y
            x_data.append (число)
            если num не 0 и num% 8 == 1:
                r = requests.get ('scheme: // device: port / rpc / get-route-engine-information @ format = json', auth = ('имя пользователя', 'пароль'))
                if r: temp_y = r.json () ["информация-о-двигателе-маршрута"] [0] ["двигатель-маршрута"] [0] ["средняя-нагрузка-один"] [0] ["данные"]
            y_data.