💡 Нажми сюда, чтобы поделиться с нами обратной связью на этот проект. Это анонимно и поможет нашей команде сделать обучение лучше. Рекомендуем заполнить опрос сразу после выполнения проекта.
[[TOC]]
В данном проекте тебе предстоит сформировать ряд коллекций запросов в Postman'е для получения данных как с публичных API без авторизации, так и с авторизацией. Ты познакомишься с концепциями протокола HTTP, его методами и форматами данных, которыми он оперирует, а также рассмотришь средства разработчика в Google Chrome.
API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».
Другими словами, API — это набор функций, который предоставляет программа, причём каждая функция описывает формат того, какие данные поступают на вход и в каком формате они будут получены. Подробнее о спецификациях API поговорим позже.
С помощью API мы можем получить доступ к данным системы, разработанной какой-либо компанией или разработчиком.
API бывают двух типов:
- Публичные — это интерфейсы, которые доступны любому человеку, и получить доступ к их использованию может любой.
- Закрытые (частные) — это интерфейсы, доступные только внутренним разработчикам или разработчикам из других команд/компаний на основе предоставления прав доступа к интерфейсу.
Ознакомиться с официальной спецификацией данной версии протокола можно тут.
HTTP (HyperText Transfer Protocol) — протокол прикладного уровня, реализованный поверх протокола TCP/IP (до версии 3.0, черновики которой работают уже поверх UDP). HTTP определяет, как взаимодействуют между собой клиент и сервер, как запрашивается и передаётся контент по интернету.
На данный момент именно благодаря протоколу HTTP (по большей части) обеспечивается работа Всемирной паутины.
API многих программных продуктов также подразумевает использование HTTP для передачи данных — сами данные при этом могут иметь любой формат, например, XML или JSON.
Как правило, передача данных по протоколу HTTP осуществляется через TCP/IP-соединения. Серверное программное обеспечение при этом обычно использует TCP-порт 80 (и если порт не указан явно, то обычно клиентское программное обеспечение по умолчанию использует именно 80-й порт для открываемых HTTP-соединений и 443 для HTTPS), хотя может использовать и любой другой.
Стартовая (начальная) строка запроса для HTTP 1.1 составляется по следующей схеме:
Метод URI HTTP/Версия
Например, такая стартовая строка может указывать на то, что запрашивается главная страница сайта:
GET / HTTP/1.1
Метод представляет собой последовательность из любых символов, кроме управляющих и разделителей, и определяет операцию, которую нужно осуществить с указанным ресурсом. Спецификация HTTP 1.1 не ограничивает количество разных методов, которые могут быть использованы, однако в целях соответствия общим стандартам и сохранения совместимости с максимально широким спектром программного обеспечения, как правило, используются лишь некоторые, наиболее стандартные методы, смысл которых однозначно раскрыт в спецификации протокола.
URI (Uniform Resource Identifier, унифицированный идентификатор ресурса) — путь до конкретного ресурса (например, документа), над которым необходимо осуществить операцию (например, в случае использования метода GET подразумевается получение ресурса).
Версия определяет, в соответствии с какой версией стандарта HTTP составлен запрос. Указывается как два числа, разделённых точкой (например, 1.1).
Пример:
GET / HTTP/1.1 Host: example.com
Первая стандартизованная версия протокола HTTP — HTTP/1.1 была опубликована в начале 1997 года, спустя несколько месяцев после появления HTTP/1.0. HTTP/1.1 на момент публикации поддерживал 7 методов: GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE. Однако позднее, в 2010 году, в стандарт был добавлен метод PATCH, а в 2014 — CONNECT.
Протокол HTTP/1.1 оказался очень удачным и стабильно прослужил в изначальной редакции более 15 лет. В процессе использования появилось только расширение протокола HTTPS, обеспечивающее шифрованную передачу данных между браузером и сервером, используя механизмы SSL/TLS.
HTTP/2 нацелен на более эффективное использование сетевых ресурсов и уменьшение видимых задержек. Это привело к созданию нового бинарного слоя формата данных, не имеющего обратной совместимости с HTTP/1.x серверами и клиентами.
Первый черновик HTTP/2 был построен на основе спецификации SPDY, а спецификация была опубликована в 2015 году. Важными аспектами стали параллелизация, приоритизация и управление потоками передачи данных:
- Под потоком понимается двунаправленная передача информации внутри установленного TCP соединения.
- Передача осуществляется посредством одного TCP соединения с любым количеством параллельных потоков.
- Такой протокол называется мультиплексированным. Несколько параллельных запросов могут использовать одно соединение.
- Это обеспечивает возможность для разной приоритизации передаваемых данных.
- Также это позволяет серверу самостоятельно инициировать передачу данных.
- Вместо текстовых данных протокол использует бинарный формат передачи данных, что позволяет увеличить производительность и безопасность.
- Заголовки запросов и ответов сжимаются принудительно.
С появлением смартфонов и множества других портативных устройств с беспроводной связью общее количество веб-трафика серьезно увеличилось. HTTP/2, работающий через TCP со своей проблемой head-of-line blocking, мог создавать задержки в запросах и ответах. Так как TCP обеспечивает строгую очерёдность передачи пакетов, то проблема с одним медленным пакетом может замедлять или вовсе ломать поток целиком. Также HTTP/2 не имел строгого требования к шифрованию данных, и по-прежнему оставались проблемы с безопасностью при перехвате заголовков запросов и ответов.
HTTP/3 проектируется для решения этих проблем и сейчас проходит тестирование с опубликованной спецификацией. Новый протокол должен решать текущие проблемы скорости, надёжности и безопасности для широкого сектора устройств.
Вместо TCP HTTP/3 строится на основе нового протокола QUIC, разрабатываемого в Google с 2012 года. QUIC работает через протокол UDP (User Datagram Protocol). QUIC сам обеспечивает мультиплексирование, и потеря одного пакета повлияет только на имеющий к этому пакету поток, другие потоки в рамках соединения продолжат свою работу. Заголовки запросов и ответов сжимаются QPACK в HTTP/2 вместо HPACK в HTTP/2. Для шифрования используется TLS 1.3, эффективно использующийся в HTTPS. Последние версии браузеров Chrome, Firefox, Edge, Opera и некоторые мобильные браузеры уже поддерживают работу по HTTP/3, но для работы должна быть и поддержка со стороны сервера.
По статистике от w3techs.com, на июль 2021 года 45.7% веб-сайтов доступны по HTTP/2 и только 20% по HTTP/3.
Строка ответа имеет следующий вид:
HTTP/Версия Код состояния Пояснение
Версия протокола здесь задаётся так же, как в запросе.
Код состояния (Status Code) — три цифры (первая из которых указывает на класс состояния), которые определяют результат совершения запроса. Например, в случае, если был использован метод GET и сервер предоставляет ресурс с указанным идентификатором, то такое состояние задаётся с помощью кода 200. Если сервер сообщает о том, что такого ресурса не существует — 404. Если сервер сообщает о том, что не может предоставить доступ к данному ресурсу по причине отсутствия необходимых привилегий у клиента, то используется код 403. Спецификация HTTP 1.1 определяет 40 различных кодов HTTP, а также допускается расширение протокола и использование дополнительных кодов состояний.
Пояснение к коду состояния (Reason Phrase) — текстовое (но не включающее символы CR и LF) пояснение к коду ответа, предназначенное для упрощения чтения ответа человеком. Пояснение может не учитываться клиентским программным обеспечением, а также может отличаться от стандартного в некоторых реализациях серверного ПО.
Пример ответа:
HTTP/1.1 200 OK Server: nginx/1.2.1 Date: Sat, 08 Mar 2014 22:53:46 GMT Content-Type: application/octet-stream Content-Length: 7 Last-Modified: Sat, 08 Mar 2014 22:53:30 GMT Connection: keep-alive Accept-Ranges: bytes
<html>
<head>
<title>Example Domain</title>
<meta charset="utf-8" />
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<style type="text/css">
body {
background-color: #f0f0f2;
margin: 0;
padding: 0;
font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", "Open Sans", "Helvetica Neue", Helvetica, Arial, sans-serif;
}
div {
width: 600px;
margin: 5em auto;
padding: 2em;
background-color: #fdfdff;
border-radius: 0.5em;
box-shadow: 2px 3px 7px 2px rgba(0,0,0,0.02);
}
a:link, a:visited {
color: #38488f;
text-decoration: none;
}
@media (max-width: 700px) {
div {
margin: 0 auto;
width: auto;
}
}
</style>
</head>
<body>
<div>
<h1>Example Domain</h1>
<p>This domain is for use in illustrative examples in documents. You may use this
domain in literature without prior coordination or asking for permission.</p>
<p><a href="https://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>С заголовками тебе предстоит разобраться самому :)
HTTP authentication — этот протокол, описанный в стандартах HTTP 1.0/1.1, существует очень давно и до сих пор активно применяется в корпоративной среде. Применительно к веб-сайтам работает следующим образом:
- Сервер при обращении неавторизованного клиента к защищенному ресурсу отсылает HTTP-статус «401 Unauthorized» и добавляет заголовок «WWW-Authenticate» с указанием схемы и параметров аутентификации.
- Браузер при получении такого ответа автоматически показывает диалог ввода username и password. Пользователь вводит детали своей учетной записи.
- Во всех последующих запросах к этому веб-сайту браузер автоматически добавляет HTTP-заголовок «Authorization», в котором передаются данные пользователя для аутентификации сервером.
- Сервер аутентифицирует пользователя по данным из этого заголовка. Решение о предоставлении доступа (авторизация) производится отдельно на основании роли пользователя, ACL или других данных учетной записи.
Мы с тобой рассмотрим наиболее популярные методы аутентификации:
- Token-Based Authentication;
- JWT Token;
- OAuth 2.0.
Token-Based Authentication
Также называют Bearer Authentication.
Token-Based Authentication использует подписанный сервером токен (bearer token), который клиент передает на сервер в заголовке Authorization HTTP с ключевым словом Bearer или в теле запроса. Например:
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IjI4Y
При получении токена сервер должен проверять его на валидность — что пользователь существует, время использования не прошло и т. д. Token-Based Authentication может использоваться как часть OAuth 2.0 или OpenID Connect протоколов, так и сервер сам может сформировать токен.
При любом способе аутентификации для безопасного использования должен использоваться протокол, который обеспечивает шифрование данных, HTTP-заголовков и URL, например, HTTPS.
JSON Web Token (JWT) — содержит три блока, разделенных точками: заголовок, набор полей (claims) и подпись. Первые два блока представлены в JSON-формате и дополнительно закодированы в формат base64. Набор полей содержит произвольные пары имя/значения, притом стандарт JWT определяет несколько зарезервированных имен (iss, aud, exp и другие). Подпись может генерироваться как при помощи симметричных алгоритмов шифрования, так и асимметричных. Кроме того, существует отдельный стандарт, описывающий формат зашифрованного JWT-токена.
Пример подписанного JWT-токена (после декодирования 1 и 2 блоков):
{ «alg»: «HS256», «typ»: «JWT» }. { «iss»: «auth.myservice.com», «aud»: «myservice.com», «exp»: «1435937883», «userName»: «John Smith», «userRole»: «Admin» }. S9Zs/8/uEGGTVVtLggFTizCsMtwOJnRhjaQ2BMUQhcY
OAuth 2.0
С помощью OAuth 2.0 пользователь разрешает определенному сайту получить свои закрытые данные из соцсетей, но без передачи сайту своих логинов/паролей. Например, когда ты регистрируешься на сайте через VK, то как раз и предоставляешь этому сайту разрешение получить из VK твои имя, e-mail-адрес и другие закрытые данные.
- GET — клиенты используют GET для доступа к ресурсам, расположенным на сервере по указанному адресу.
- POST — используется для отправки данных на сервер.
- PUT — для создания или обновления существующего ресурса целиком.
- PATCH — для обновления части существующего ресурса.
- DELETE — для удаления ресурса.
Программа Postman предназначена для тестирования работы API, а также для отправки запросов POST и GET и др. В отличие от похожей утилиты curl, она имеет графический интерфейс, поэтому легко осваивается даже новичками.
Скачать ее можно с официального сайта — есть дистрибутивы для Windows, macOS и Linux. На последней платформе есть возможность установки утилиты напрямую из Центра приложений. В любом случае использование начинается с регистрации бесплатного аккаунта.
Тестирование интерфейса API проводится путем анализа точности выходных данных в зависимости от подаваемых при входном запросе. Этим и занимается Postman: он составляет и отправляет их на указанные URL, получает обратно и сохраняет в базе данных. При желании возможно сохранение типовых запросов в коллекции (для быстрого доступа) и создание для них разного окружения.
Ну что, давай знакомиться с API. Результатом каждого направления является коллекция Postman.
Для начала тебе необходимо перейти по ссылке и получить API KEY (Ключ интерфейса прикладного программирования — это уникальный идентификатор, используемый для аутентификации пользователя, разработчика или вызывающей программы.).
Не забудь, что API KEY нужно прикладывать в качестве bearer token в заголовке авторизации!
- Необходимо получить все новости по теме linux.
- Получить все новости по теме «Разработка» на русском языке за последние 15 дней.
- Получить все новости по теме linux на русском языке на 3 странице, на каждой из которых по 10 новостей.
- Получить все заголовки новостей для страны Россия по теме «наука» (science).
Результатом выполнения данного задания является постман-коллекция.
А сейчас мы с тобой полезем на сайт hh.ru для того, чтобы достать данные с их API (не с сайта). Для этого тебе необходимо открыть консоль разработчика, выбрать вкладку «network» (Сеть), указать фильтр на Fetch/XHR и выполнять рандомные действия на сайте. Необходимо получить контакты какой-либо вакансии (ищи кнопку «показать контакты» и жми!).
В результате прокликивания разных кнопок и ссылок в разделе network ты увидишь запросы, которые посылаются на API hh.ru (В URI запроса не обязательно должен присутствовать тег «api»). Выполни этот же запрос в Postman и убедись, что полученные тобой данные «где-то» присутствуют на сайте. Таким образом, мы с тобой посмотрим на то, как в действительности работают веб-приложения, и на то, как они коммуницируют. (Причём открытой, доступной для всех спецификации этого API попросту нет).
Полученный в результате запрос должен начинаться с https://hh.ru/vacancy/...
Известное нынче средство автоматизации бизнеса — хороший сайт телеграм-бот! Сделать его сейчас проще простого, особенно благодаря официальной документации.
Написание собственных ботов доступно благодаря открытому Telegram API. Именно потому, что оно открытое, существуют десятки библиотек, которые по-своему реализуют доступные функции бота.
Мы своего бота писать не будем, но... Подёргаем его за «ниточки», предоставленные нам официальным API. В этом задании ты потренируешься делать запросы через Postman к апишке и будешь сразу видеть результаты! А ещё ты увидишь, как просто реализовать свою библиотеку для работы с телеграм-ботами.
Итак, задание:
- Создай своего бота. Это делается абсолютно бесплатно через BotFather. Не забудь сохранить токен!
- Изучи, в каком формате посылаются запросы к боту через api.telegram.org.
- Создай коллекцию в Postman. Последующие запросы добавляй в неё.
- Получи информацию о боте (метод getMe).
- Отправь сообщение боту (например, просто /start).
- Ищи информацию о себе в ответе на метод getUpdates! Сохрани свой user_id и chat_id.
- А теперь отправь себе сообщение от имени бота (sendMessage).
- Так-так, теперь можно отправить фотографию себе от имени бота. Потренируйся прикреплять файлы к запросу (в разделе Body через form-data).
- А что, если теперь в том же методе sendPhoto вместо фотографии прикрепить pdf-документ? Результат точно удивит!
- Теперь вместо pdf-документа попробуй прикрепить docx-файл. Какой будет ответ?
- Напоследок посмотрим, что бот может узнать о тебе. Например, твои фотографии. Попробуй отправить запрос с методом getUserProfilePhotos.
Результатом задания является коллекция Postman (минимум 7 запросов). Замечание: не забывай о разнице GET- и POST-запросов!
Полезные ссылки: