Тема 35. HTTP и REST - BelyiZ/JavaCourses GitHub Wiki
- Обзор протокола HTTP
- Обзор подходов построения REST API
- Форматы данных (JSON, XML, YAML)
- Список литературы/курсов
Речь пойдет о протоколах передачи данных по сети на прикладном уровне модели OSI.
Протокол передачи данных - общепринятое соглашение, благодаря которому разработчики разных сервисов отправляют информацию в едином виде. Единые правила очень удобны и самим разработчикам серверных частей: существует очень много библиотек, которые могут за тебя преобразовать информацию и отправить по необходимому протоколу.
Изначально HTTP задумывался как протокол передачи HTML-страниц. Долгое время так и было, но сейчас программисты частенько передают по нему и строки, и медиафайлы. В общем, этот протокол универсальный и гибкий, и использовать его действительно просто.
Структура HTTP Сразу стоит отметить, что HTTP-протокол состоит только из текста. Ну а нас больше всего интересует структура, в которой расположен этот текст.
Каждое сообщение состоит из трех частей:
- Стартовая строка (Starting line) — определяет служебные данные.
- Заголовки (Headers) — описание параметров сообщения.
- Тело сообщения (Body) — данные сообщения. Должны отделяться от заголовков пустой строкой.
По HTTP-протоколу можно отправить запрос на сервер (request) и получить ответ от сервера (response). Запросы и ответы немного отличаются параметрами.
Как выглядит простой HTTP-запрос
GET / HTTP/1.1
Host: reksoft.ru
User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7)
В стартовой строке указаны:
GET — метод запроса;
/ — путь запроса (path);
HTTP/1.1 — версия протокола передачи данных.
Затем следуют заголовки:
Host — хост, которому адресован запрос;
User-Agent — клиент, который отправляет запрос.
Тело сообщения отсутствует.
В HTTP-запросе обязательны только стартовая строка и заголовок Host.
Теперь разберем все по порядку.
HTTP-запрос должен содержать какой-то метод.
Всего их девять: GET, POST, PUT, OPTIONS, HEAD, PATCH, DELETE, TRACE, CONNECT.
Самые распространенные — GET и POST.
GET — запрашивает контент из сервера. Поэтому у запросов с методом GET нет тела сообщения. Но при необходимости можно отправить параметры через path в таком формате:
Здесь: reksoft.ru — хост. /send — путь запроса. ? — разделитель, обозначающий, что дальше следуют параметры запроса.
В конце перечисляются параметры в формате ключ=значение, разделенные амперсандом.
POST — публикует информацию на сервере.
POST-запрос может передавать разную информацию: параметры в формате ключ=значение, JSON, HTML-код или даже файлы.
Вся информация передается в теле сообщения.
Например:
POST /user/create/json HTTP/1.1 Accept: application/json Content-Type: application/json Content-Length: 28 Host: reksoft.ru
{ "Id": 12345, "User": "John" }
Запрос отправляется по адресу reksoft.ru/user/create/json, версия протокола — HTTP/1.1. Accept указывает, какой формат ответа клиент ожидает получить, Content-Type — в каком формате отправляется тело сообщения. Content-Length — количество символов в теле.
HTTP-запрос может содержать много разных заголовков.
Подробнее с ними можно ознакомиться в спецификации протокола.
HTTP-ответы
После получения запроса, сервер его обрабатывает и отправляет ответ клиенту:
HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Content-Length: 98
<title>An Example Page</title>Hello World
Стартовая строка в респонсе содержит версию протокола (HTTP/1.1), Код статуса (200), Описание статуса (OK). В заголовках — тип и длина контента. В теле ответа — HTML-код, который браузер прорисует в HTML-страницу.
Response Status Codes
С телом сообщения и заголовками все ясно, а о кодах статусов стоит сказать пару слов.
Response Status Codes - это Код ответа (состояния) HTTP.
Response Status Codes всегда трехзначные, и первая цифра кода указывает класс ответа:
1xx — информационный. Запрос получен, сервер готов к продолжению;
2xx — успешный. Запрос получен, понятен и обработан;
3xx — перенаправление. Следующие действия нужно выполнить для обработки запроса;
4xx — ошибка клиента. Запрос содержит ошибки или не отвечает протоколу;
5xx — ошибка сервера. Сервер не смог обработать запрос, хотя был составлен верно;
Вторая и третья цифры в коде детализируют ответ.
Например: 200 OK — реквест получен и успешно обработан; 201 Created — реквест получен и успешно обработан, в результате чего создан новый ресурс или его экземпляр; 301 Moved Permanently — запрашиваемый ресурс был перемещен навсегда, и последующие запросы к нему должны происходить по новому адресу; 307 Temporary Redirect — ресурс перемещен временно. Пока к нему можно обращаться, используя автоматическую переадресацию; 403 Forbidden — запрос понятен, но нужна авторизация; 404 Not Found — сервер не нашел ресурс по этому адресу; 501 Not Implemented — сервер не поддерживает функциональность для ответа на этот запрос; 505 HTTP Version Not Supported — сервер не поддерживает указанную версию HTTP-протокола. Вдобавок к статус-коду ответа также отправляется описание статуса, благодаря которому интуитивно понятно, что значит конкретный статус.
HTTP-протокол очень практичен: в нем предусмотрено большое количество хедеров, используя которые можно настроить гибкое общение между клиентом и сервером.
HTTP-протокол принято использовать на порту 80, поэтому когда ты видишь адрес, который заканчивается портом 80, можешь быть уверен, что к нему нужно обращаться по HTTP.
С развитием технологий и активным перемещением персональных данных в интернет пришлось задуматься о том, как обеспечить дополнительную защиту информации, которую клиент передает серверу. В результате появился протокол HTTPS.
Отличие между HTTPS и HTTP HTTPS синтаксически идентичен протоколу HTTP, то есть использует те же стартовые строки и заголовки. Единственные отличия — дополнительное шифрование и порт по умолчанию (443).
HTTPS шифруется между HTTP и TCP, то есть между прикладным и транспортным уровнями.
Современный стандарт шифрования — по протоколу TLS. Шифрование происходит перед тем, как информация попадает на транспортный уровень. В HTTPS шифруется абсолютно вся информация, кроме хоста и порта, куда отправлен запрос.
Для перевода сервера на использование HTTPS протокола вместо HTTP, не нужно менять код сервера.
REST API обеспечивают гибкую, упрощенную интеграцию приложений, а также являются самым популярным методом связывания компонентов в микросервисных архитектурах.
API или программный интерфейс приложения представляет собой набор правил, определяющих способ взаимодействия между приложениями или устройствами.
REST API — это API, соответствующий принципам архитектурного стиля REST (representational state transfer — "передача состояния представления" или, лучше сказать, представление данных в удобном для клиента формате).
То есть по сути, REST — не протокол и не стандарт, а подход, архитектурный стиль проектирования API.
По этой причине REST API иногда называют RESTful API.
Основная идея REST в том, что каждое обращение к сервису переводит клиентское приложение в новое состояние.
REST (сам термин был введен Роем Филдингом в его докторской диссертации в 2000 году) обеспечивает относительно высокий уровень гибкости и свободы для разработчиков.
Но гибкость — лишь одна из причин, объясняющих популярность REST API как способа взаимодействия между компонентами и приложениями в микросервисной архитектуре.
На самом базовом уровне API можно представить как механизм, с помощью которого одно приложение или сервис может получить доступ к ресурсу другого приложения или сервиса.
Приложение или сервис, запрашивающий доступ, называется клиентом, а приложение или сервис, обладающий необходимым ресурсом, называется сервером.
Принципы REST API
-
Единый интерфейс. Все запросы
APIк одному и тому же ресурсу должны выглядеть одинаково, независимо от отправителя. ВREST APIодин и тот же элемент данных, например имя или адрес электронной почты пользователя, должен принадлежать одному универсальному коду ресурса (URI). Размер ресурсов не должен быть слишком большим, однако ресурсы должны содержать всю информацию, которая может потребоваться клиенту. -
Разделение клиента и сервера. В соответствии с требованиями
REST APIклиент и сервер должны работать полностью независимо друг от друга. Клиентскому приложению достаточно знатьURIзапрашиваемого ресурса; иначе взаимодействие с серверным приложением будет невозможно. Аналогичным образом, серверное приложение не должно вносить никаких изменений в клиентское приложение, а только передавать запрошенные данные черезHTTP. -
Отсутствие сохранения состояния.
REST APIфункционируют без сохранения состояния, то есть каждый запрос должен содержать всю информацию, необходимую для его обработки. Другими словами, дляREST APIне требуется установление постоянных сеансов с сервером. Серверным приложениям запрещено хранить какие-либо данные, связанные с запросом клиента. -
Поддержка кэширования. По возможности ресурсы должны поддерживать кэширование на стороне клиента или сервера. Ответы сервера также должны хранить информацию о том, разрешено ли кэширование для предоставленного ресурса. Это позволяет увеличить производительность на стороне клиента, одновременно повысив масштабируемость на стороне сервера.
-
Многоуровневая архитектура системы. В
REST APIвызовы и ответы передаются через разные уровни. Предполагается, что клиентское и серверное приложения не взаимодействуют между собой напрямую. Цепочка передачи данных может включать несколько промежуточных узлов.REST APIдолжны проектироваться таким образом, чтобы ни клиент, ни сервер не могли знать, взаимодействуют они с конечным приложением или промежуточным узлом. -
Код по требованию (необязательное требование).
REST APIобычно отправляют статические ресурсы, однако в некоторых случаях ответ может содержать исполняемый код (например,Java-апплеты). В таких случаях код должен выполняться только по требованию.
Принципы работы REST API
REST API используют запросы HTTP для выполнения стандартных функций базы данных, таких как создание, чтение, обновление и удаление записей (так называемые функции CRUD).
Например, REST API может использовать запрос GET для получения записи, запрос POST для создания записи, запрос PUT для обновления записи и запрос DELETE для удаления записи.
В вызовах API поддерживаются все методы HTTP. Хорошо продуманный REST API можно сравнить с веб-сайтом, который работает в веб-браузере со встроенной поддержкой HTTP.
Состояние ресурса в любой момент времени («отметка времени») называется представлением ресурса.
Эта информация может быть предоставлена клиенту практически в любом формате, включая JavaScript Object Notation (JSON), HTML, XLT, Python, PHP или текстовом формате.
Популярность JSON обусловлена тем, что данный формат не зависит от языка программирования и понятен как человеку, так и компьютеру.
Важную роль в вызовах REST API также играют заголовки и параметры запросов, поскольку они содержат такую важную информацию, как метаданные, разрешения, универсальные коды ресурсов (URI), сведения о кэшировании, файлы cookie и многое другое.
Заголовки запросов и ответов применяются в хорошо продуманных REST API вместе с обычными кодами состояния HTTP.
Преимущества REST API
- Возможно переиспользовать существующие стандарты, которые применяются на многих устройствах.
-
RESTосновывается наHTTP, поэтому доступно: Кэширование, Масштабирование, Стандартные коды ошибок. - Очень хорошая распространенность (даже IoT-устройства уже умеют работать на
HTTP).
Рекомендации по использованию REST API
С одной стороны, гибкость является огромным преимуществом при проектировании REST API; с другой стороны, гибкость может стать причиной дефективного или неэффективного API.
По этой причине профессиональные разработчики делятся передовыми практиками в спецификациях REST API.
Спецификация OpenAPI (OAS) определяет интерфейс для описания API, чтобы обеспечить разработчикам и приложениям полное понимание всех параметров и возможностей API, включая доступные конечные точки, разрешенные операции для каждой конечной точки, параметры операций, методы аутентификации и прочую информацию.
Последняя версия, OAS3, содержит полезные инструменты, например OpenAPI Generator, для создания клиентов API и серверных заглушек на разных языках программирования.
Для обеспечения безопасности REST API также следует опираться на передовой отраслевой опыт, в частности использование алгоритмов хэширования для защиты паролей и HTTPS для безопасной передачи данных.
Для ограничения прав доступа сторонних приложений можно использовать инфраструктуру авторизации, например OAuth 2.0 (внешняя ссылка).
Кроме того, API может отклонять любые запросы, поступающие по истечении определенного периода времени, используя отметку времени в заголовке HTTP.
Существуют и другие способы контроля доступа к API: проверка параметров и веб-маркеры JSON.
В настоящее время существует значительное количество различных форматов, рекомендуемых в литературе для использования в распределенных информационных системах.
Чаще всего в сообществе разработчиков, предпочтение отдают одному из трёх наиболее используемых форматов обмена данными: XML, JSON, YAML.
XML (Extensible Markup Language) – простой, очень гибкий текстовый формат, являющийся подмножеством SGML (ISO 8879), который позволяет определять собственные теги и атрибуты.
Язык называется расширяемым, поскольку он не фиксирует разметку, используемую в документах: разработчик волен создать ее в соответствии с особенностями конкретной предметной области, будучи ограниченным лишь синтаксическими правилами языка.
Возможность создания собственных тегов делает XML универсальным.
JSON (Java Script Object Notation) – представляет собой облегченный формат обмена данными между компьютерами.
В соответствии с определением стандарта сценарного языка программирования ECMA (Европейской ассоциации производителей компьютеров), он является производным от литералов Java Script. JSON более компактен, чем XML, его конструкции легче анализируются средствами Java Script, для которого JSON является внутренним используемым типом данных.
Основная сфера применения JSON – программирование web-приложений, где он служит альтернативой XML.
YAML – человекочитаемый формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования. В настоящее время акроним YAML интерпретируется как «YAML Ain’t Markup Language» («YAML – не язык разметки»). В названии отражена история развития: на ранних этапах акроним представлял собой аббревиатуру выражения «Yet Another Markup Language» («Ещё один язык разметки») и даже рассматривался как конкурент XML, но позже был переименован, чтобы акцентировать внимание на данных, а не на разметке документов.
В настоящее время не существует сформулированных критериев, благодаря которым можно было бы сравнить форматы обмена данными в приложениях с клиент-серверной архитектурой.
- Человекочитаемость – предполагает простую и удобную разметку передаваемых данных. При этом язык должен иметь незначительное количество символов-разделителей (скобки, кавычки и т.д.).
- Простота сериализации – преобразования объекта (данных) в поток байтов для дальнейшего хранения или передачи по каналу связи, в память или файл.
- Простота десериализации – преобразования потока байтов в объект данных.
- Возможность проверки формата входных данных – наличие в формате обмена данными внутреннего языка описания структуры документа (
JSON-Schema,XML-Schema), необходимого для осуществления предварительной проверки на соответствие приходящих данных, например, со стороны клиента. - Эффективность сжатия данных – включает скорость выполнения алгоритма компрессии и коэффициент сжатия.
- Распространенность – наличие большого количества разработчиков, использующих тот или иной формат обмена данными.
- Динамика развития, которая характеризуется скоростью популяризации и развития.