Всемирная паутина состоит из большего количества компонентов, чем те, которые открываются пользователям, когда они заходят на веб-сайт. Как пользователи-люди, так и машины получают доступ к данным с веб-проектов. Для того чтобы это работало, операторы веб-сайтов должны сделать свой сайт доступным для других приложений, предоставив соответствующий веб-сервис.
В качестве примера можно привести социальную сеть Twitter; благодаря соответствующим веб-сервисам любое приложение может считывать или писать твиты от имени пользователя.
Существуют различные методы реализации таких веб-служб: удаленные вызовы процедур (RPC), сетевой протокол SOAP или парадигма программирования Representational State Transfer (REST).
Что же такое REST?
Термин «передача состояния представления» (Representational State Transfer) происходит из диссертации, опубликованной Роем Филдингом, одним из главных разработчиков множества различных веб-стандартов. В абстрактной форме компьютерный ученый описывает лежащую в основе архитектуры Всемирной паутины (протокол HTTP, HTML и XML, парсер, веб-серверы и серверы приложений и т.д.). Вообще говоря, архитектура REST не зависит от каких-либо конкретных протоколов. В центре этой концепции находятся ресурсы, которые, по словам Филдинга, должны отвечать следующим требованиям:
- Адресность: каждый ресурс, например, заказ, продукт или статья, должен быть идентифицирован с помощью уникального идентификатора ресурса (URI).
- Унифицированные интерфейсы: каждый ресурс должен быть легко и единообразно доступен с помощью стандартных методов. Например, с помощью методов HTTP, таких как ‘GET’, ‘POST’ или ‘PUT’.
- Структура клиент-сервер: в общем случае применяется принцип клиент-сервер: Сервер предоставляет услугу, которая при необходимости может быть запрошена клиентами.
- Нестационарность: коммуникация между серверами и клиентами является нестационарной. Это означает, что все обмениваемые сообщения содержат всю информацию, необходимую для их понимания. Сервер не сохраняет никакой дополнительной информации между двумя сообщениями в виде сессий. А учитывая, что входящие запросы могут быть перераспределены с помощью схемы балансировки нагрузки, отсутствие статичности делает сервисы REST очень простыми в масштабировании.
- Различные представления ресурсов: каждый веб-ресурс может иметь несколько форматов отображения. В зависимости от того, что запрашивает клиент, эти ресурсы могут быть предоставлены на разных языках или в разных форматах, таких как HTML, JSON или XML.
- Гипермедиа: ресурсы предоставляются через гипермедиа, например, в виде атрибутов ‘href’ и ‘src’ в HTML-документах. Они также могут быть предоставлены через определенные интерфейсы JSON или XML. Следовательно, клиент REST-API осуществляет навигацию в соответствии с методом «гипермедиа как двигатель состояния приложения» (HATEOAS) исключительно по URL-адресам, которые были предоставлены сервером; они не требуют никакой дополнительной информации об интерфейсе.
Строгие стандарты архитектуры REST позволяют разрабатывать сервисы, которые взаимодействуют по общему протоколу (HTTP), хорошо структурированы и легко интегрируются.
Разбор конструкции службы REST
Для реализации REST-сервиса в основном используется протокол HTTP и его зашифрованный родственник HTTPS. Одной из причин этого является широкое применение этих протоколов, что позволяет пользователям проходить практически через любой брандмауэр. Альтернативный протокол Hypertext Transfer Protocol, не имеющий статусов, также имеет относительно простую структуру. Стандарт HTTP имеет полный набор команд, с помощью которых можно получить доступ к ресурсам:
| HTTP Method (Command) | Описание |
|---|---|
| GET | Запрашивает ресурс у сервера без изменения его состояния на сервере. |
| POST | Создает новый ресурс под указанным ресурсом, который автоматически адресуется URI; или изменяет существующий ресурс. |
| HEAD | Запрашивает у сервера только заголовок соответствующего ресурса. Это делается, в частности, для проверки достоверности файла. |
| PUT | Создает указанный ресурс на сервере или модифицирует существующий. |
| PATCH | Изменяет часть указанного ресурса. |
| DELETE | Удаляет соответствующий ресурс. |
| TRACE | Возвращает запрос в том же виде, в котором его получил веб-сервер, чтобы определить, произошли ли какие-либо изменения на пути к серверу. |
| OPTIONS | Показывает список методов, поддерживаемых сервером. |
| CONNECT | Запускает запрос через SSL-туннель. Обычно это делается для того, чтобы создать соединение через прокси-сервер. |
Этот диапазон команд может быть расширен путем внедрения дополнительных протоколов. Для этого часто используется протокол WebDAV. При этом добавляются методы COPY (копирует ресурс), MOVE (перемещает ресурс), LOCK (блокирует ресурс), UNLOCK (разблокирует ресурс) и MKCOL (создает каталог).
Для каких веб-служб лучше всего подходит архитектура REST?
Как правило, при разработке REST-сервиса через HTTP используются стандартные методы GET, POST, PUT, PATCH и DELETE, что говорит о том, что архитектура была разработана только для простых задач управления данными. Более того, принцип безграмотности ресурсов REST также существенно ограничивает возможности архитектуры. Однако при правильном использовании ресурсов интерфейс REST позволяет делать больше, чем просто добавлять и извлекать наборы данных, что демонстрируют следующие примеры.
- Веб-сервисы с транзакциями: Менеджеры транзакций необходимы для реализации веб-сервисов с транзакциями. Из-за отсутствия статичности ресурсы всегда сохраняются без дополнительной информации между запросами. Это означает, что реализация REST ограничена двумя различными вариантами:
- Ресурсы разрабатываются таким образом, чтобы транзакции могли обрабатываться в рамках одного запроса.
- Создается ресурс, который управляет запросами транзакций. Каждый запрос, представленный этому менеджеру транзакций, автоматически генерирует дополнительный ресурс, который затем идентифицируется через URI и представляет собой транзакцию. Впоследствии изменения могут быть внесены как представления этого ресурса на сервере. Следующий запрос к менеджеру транзакций завершает транзакцию.
- Асинхронные веб-сервисы: для некоторых веб-сервисов может потребоваться, чтобы запросы и ответы были отделены друг от друга по времени. Учитывая, что HTTP не предлагает никаких механизмов для решения этой задачи, единственным вариантом, доступным поставщикам серверов, является самостоятельная обработка запросов и пересылка их на запросы пользователей.
- Веб-сервисы с широкой функциональной совместимостью: REST-сервисы характеризуются своей гибкостью. Эта гибкость обусловлена тем, что основное внимание уделяется одному базовому протоколу и что мобильные клиенты особенно выигрывают от ограниченных требований архитектуры REST. Тот факт, что эти ресурсы легко доступны, также позволяет поисковым системам находить их без посторонней помощи.
Программирование веб-служб с помощью REST
Фреймворк REST предлагает отличные средства для разработки и реализации различных видов веб-служб. Благодаря тому, что протокол Hypertext Transfer Protocol поддерживается практически всеми устройствами, как настольные, так и мобильные клиенты могут легко работать с интерфейсом REST без необходимости дополнительных реализаций. В результате получаются веб-сервисы, обладающие значительной степенью:
- независимость от платформы,
- масштабируемость,
- производительность,
- интероперабельность,
- и гибкости.
Использование этой архитектуры требует соответствующих ноу-хау. Особенно управление взаимодействием между отдельными ресурсами, не имеющими статического характера, является сложной и труднодостижимой задачей. Те, кто уже работал с альтернативами, такими как протокол SOAP, наверняка задумаются над необычными подходами, используемыми в этой архитектуре; однако REST оказывается гораздо более полезным сервисом.
- Ноу-хау