“REST” – это не про “отдых”.
Часть первая: что такое архитектура REST?


Disclaimer:
1) Часть 1 – теоретическая, может быть скучно :);
2) если вы до этого сталкивались и работали с протоколом HTTP (знаете, как устроен, формат запроса/ответа) – проблем с пониманием REST у вас возникнуть не должно. Если не уверены – рекомендую сначала почитать
про HTTP на Википедии.


Начнем.

Из википедии: REST(Representational State Transfer) — архитектурный стиль взаимодействия компонентов распределённого приложения в сети.

Для веб-сервисов или API, построенных с учётом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful».

Термин REST был введен в 2000 году Роем Филдингом, одним из авторов HTTP-протокола.

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

Очень важно следующее: REST – это НЕ протокол или стандарт.
В отличие от веб-сервисов на основе SOAP, не существует утвержденного или принятого официально стандарта для RESTful сервисов. REST является архитектурой, в то время как SOAP является протоколом.

То есть REST – это набор принципов и ограничений взаимодействия клиента и сервера в сети интернет, использующий существующие стандарты (HTTP протокол, стандарт построения URL, форматы данных JSON и XML) в ходе взаимодействия.

Правила и ограничения REST-архитектуры

В REST есть шесть основных ограничений:

1) Модель взаимодействия клиент-сервер.

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

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

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

2) Отсутствие состояния.

Согласно REST, сервис не хранит результаты предыдущей операции. То есть работаем по принципу “спросил-ответил-забыл”. 🙂

3) Кэширование.

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

4) Единообразие интерфейса.

REST-архитектура определяет, что любой REST-сервис должен быть понятен без его разработчика. Для этого REST вводит четыре правила:

  • Идентификация ресурсов.

Чтобы отделить один ресурс(сервис) от другого используются запросы/ссылки (URI).

Пример: информация по ISBN-коду книги в библиотеке – http://library.net/books/info/<ISBN>
продление книги по ISBN – http://library.net/books/prolong/<ISBN>

Пример неподходящего разделения: http://library/books/operation, где операция и код книги должны быть в теле запроса.

  • Манипуляция ресурсами через представление.

По простому: если мы получили мета-данные по объекту (из предыдущего примера – код ISBN книги) – то можем сделать с этим объектом любую операцию из состава API.

  • «Самоописываемые» сообщения.

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

  • Гипермедиа как способ определить состояние приложения.

Гипермедиа – это расширение термина гипертекст. Если упростить – то это все интерактивные объекты сети: рисунки, схемы, видео (пример – youtube), текст и ссылки.

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

5) Слои.

Клиент не должен знать, работает ли он с конечной точкой, или с цепочкой/иерархией серверов. То есть REST предусматривает возможность кластерной/распределенной работы серверной части, но при этом для клиента сервис должен оставаться цельным и не требовать дополнительных данных/действий от клиента.

6) Код по требованию (необязательное ограничение).

Тут разработчик архитектуры REST предложил следующее – по запросу, сервис должен отдавать исполняемый код в виде апплета или сценария, для выполнения на стороне клиента. На практике – практически не используется.

RESTful сервис

С точки зрения пользователя, RESTful сервисы – это ресурсы сети, которыми может быть всё, что можно поименовать и представить.

Сервисы описывают себя сами. Ну или пытаются :), но чем логичней и понятней система наименования (url) – тем удобнее работать с API.
Поэтому api/books/get/ISBN/2-266-11156 лучше и понятней, с точки зрения клиента, чем /api?obj=books&func=get&search=ISBN&number=2-266-11156

В ресурсах содержатся ссылки на другие ресурсы (гиперсреда). То есть, получив первичную информацию по объекту, в составе ответа может быть ссылка на ресурс, дающий полную информацию по этому объекту.

Пример: Используя REST API находим книгу по url api/books/get/ISBN/2-266-11156. В ответе сервис высылает блок информации, в нем есть элемент infolink, содержащий ссылку api/books/info/2-266-11156.

Взаимодействие с ресурсами осуществляется с помощью вызова URL ресурса и стандартных команд HTTP (GET, POST, PUT и DELETE). Эти операции обычно соответствуют операциям с объектом, например, так:

 

Create PUT (с пустым ID объекта)
POST
Read GET
Update PUT (с существующим ID объекта)
Delete DELETE

Ответ сервис также отправляет в виде кода возврата HTTP, например:

200 Ок
404 Не найден
400 Плохой запрос (Bad Request)
500 Внутренняя ошибка сервера

На деле кодов возврата у HTTP существенно больше (wiki – HTTP codes). Также дополнительные данные об ошибке могут передаваться в теле ответа.

Формат данных, передаваемых между клиентом и сервисом указывается с помощью заголовка HTTP – параметр типа содержимого Content-Type. Обычно это JSON или XML, но могут быть разнообразными (например, JPG, PNG – для сервиса обработки графики).

JSON vs XML

Для специалистов, работающих с SAP PI/PO, XML – это практически второй родной язык. 🙂 JSON же в мире SAP практически не используется, поэтому уделю немного внимания этой теме.

JSON – структурированный формат передачи данных, такой же, как XML, только вместо тегов структура организуется с помощью скобок, кавычек и знаков препинания:
{"books":[
{ "title":"Золотой ключик или приключения Буратино", "price":300 },
{ "title":"Десять негритят", "price":500.10 },
{ "title":"Большая Советская Энциклопедия", "price":10000 }
]}

Сходство JSON и XML:
Это понятные языки – их можно читать без специального ПО и понимать содержимое;
Это иерархичные языки – данные организованы при помощи различных уровней вложенности;
Для получения данных/значений XML/JSON нужно разобрать – подвергнуть “парсингу”,”распарсить”.

Основные различия:
JSON компактнее (данные в формате JSON имеют меньший размер, чем в XML);
JSON быстрее в чтении/передаче данных;
JSON позволяет вариативность типов/структур (например, в JSON-схеме разрешены элементы, имеющие один из нескольких типов – в схеме данных можно определить, что элемент price может быть текстом, а может быть структурой из двух элементов). После привычки к строгости XML вариативность JSON сложно понять и принять. 🙂

Использование REST API

На данный момент практически каждый крупный интернет-ресурс имеет свой REST API:

 

Поэтому хорошему интегратору надо уметь с ними работать. Разработчики SAP это учли – и выпустили адаптер к SAP Process Integration для поддержки REST.

А вот как с ним работать – будет в следующей серии. 🙂

Ваш Питрофф.


Дополнительная информация:


2 thoughts on ““REST” – это не про “отдых”.
Часть первая: что такое архитектура REST?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *