3) подраздел 6.3 — показывает возможности потребителей сервиса.
6.1 Основные положения технологии RESTful
Web-службы, построенные с учетом ограничений REST-технологий, называются RESTfulсистемами.
В отличие от Web-сервисов, построенных на основе протокола SOAP, RESTful-системы не имеют официального стандарта на свое API, поэтому принято считать, что — это архитектурный стиль программирования.
RESTful — это архитектурный стиль проектирования и реализации сер- вис-ориентированных систем.
Считается, что во многом идейной парадигмой технологии REST стала стандартная классификация действий по работе с базами данных CRUD, которая была введена Джеймсом Мартином в 1983 году.
CRUD — это акроним, обозначающий четыре базовых действия (функций) для работы с базами данных:
1)CREATE — создание записей (INSERT);
2)READ — чтение записей (SELECT);
3)UPDATE — модификация записей;
4)DELETE — удаление записей.
Применительно к Web-службам, термин CRUD проецируется на четыре HTTP-запроса к Web-серверам:
1)POST — запрос на создание ресурса;
2)GET — запрос на получение ресурса;
3)PUT — запрос на модификацию ресурса;
4)DELETE — запрос на удаление ресурса.
Сам термин REST был введен Роем Филдингом в 2000 году и упоминается в ключе его докторской диссертации: «Архитектурные стили и дизайн сетевых программных архитектур». Им было предложено и шесть ограничений, нарушение которых не позволяет считать сервис-приложение REST-системой:
1.Модель «Клиент-сервер» — предполагается приведение приложения, возможно целостного по начальной реализации, к архитектуре, где выделены поставщик сервиса и потребители сервиса. Это улучшает мастабируемость приложения и позволяет отдельным частям развиваться независимо друг от друга.
2.Отсутствие состояния — обеспчение на стороне сервера протокола взаи-
234
модействия без сохранения состояния. При этом, состояние сессии должно сохраняться на стороне клиента (потребителя сервиса).
3.Кэширование ответов сервера — способность сервера или промежуточных узлов кэшировать свои ответы. Это позволяет повысить производительность и расширяемость системы.
4.Единообразие интерфейсов сервисов — фундаментальное требование дизайна REST-сервисов. Унификация интерфесов должна соответствовать четырем дополнительным условиям: идентификации ресурсов посредством URI; возможности манипуляции ресурсов на основе представлений; использованию «самозаписываемых» сообщений и применению гипермедиа как средства изменения состояния приложения.
5.Слои взаимодействия — использование взаимодействия клиента и сервера на основе иерархической структуры сетей.
6.Код по требованию (необязательное ограничение) — возможность расширения функциональности клиентов за счет загрузки кода с серверов приложений в виде апплетов или сценариев.
По мнению Роя Филдинга, приложения, не соответствующие приведенным условиям, не могут называться REST-приложениями.
По мнению Филдинга, приложения, которые соответствуют указанным выше шести условиям, получают следующие преимущества:
а) надежность по причине отсутствия необходимости сохранять информацию о состоянии клиента, поскольку она может быть утеряна;
б) производительность за счет использования кэша и масштабируемость
за счет разделения поставщиков и потребителей сервисов;
в) простота интерфейсов и портативность компонентов создаваемых сервисных систем;
г) легкость внесения изменений и способность «эволюционировать» под воздействием новых требований к системам.
Основной недостаток REST-технологий — отсутствие формальной стандартизации, четко ограничивающей их объективное присутствие.
Имеющиеся недостатки REST-технологий являются продолжением их преимуществ. Действительно, REST-технологии полностью ориентированы на использование только Web-технологий, что в конечном итоге приводит к существенному развитию последних, но ограничивает первых.
235
Чтобы не впадать в крайности популистских утверждений, рассмотрим заявленную тематику данного подраздела только в следующих трех аспектах:
1)общие понятия и обозначения изучаемой тематики в планах ресурсов, адресации и других представлений, используемых в теоретических описаниях технологий REST;
2)возможности протокола HTTP и перспективы использования языка WADL;
3)описание технологии JAX-RS, как основного инструментального средства реализации конкретных REST-систем посредством программной платформы Java EE.
6.1.1 Ресурсы, URI, представления и адресуемость
Базовым понятием Web-технологий является понятие ресурса.
REST-технологии можно рассматривать как дальнейшее развитие Webтехнологий применительно к распределенным сервис-ориентированным системам. Соответственно, в REST-технологиях, в явном или неявном виде, присутствуют такие понятия как ресурсы, URI/URN, представления и адресуемость.
Ресурс — это зонтичный термин, обозначающий любую сущность, на которую клиент (потребитель сервиса) может поставить ссылку или с которой он пытается или может попытаться взаимодействовать. В такой интерпретации, ресурсы могут обозначать что угодно: файлы в файловой системе, базу данных, сайт или любую информацию, которая попала в поле зрения пользователя.
URI (Uniform Resource Identifier) — унифицированный или единообразный идентификатор ресурса, имеющий две базовые интерпретации:
1)URL (Uniform Resource Locator) — система унифицированных адресов электронных ресурсов, которая в современном понимании соответствует понятию URI;
2)URN (Uniform Resource Name) — единообразное название или имя ресурса, которые не включают в себя указания на местонахождение и способ обращения к ресурсу.
Что касается тематики REST-технологий, то под URI понимается именно URL, указывающий на местоположение ресурса в формате:
http://host:port/path?queryString#fragment, где http — протокол соединения с ресурсом;
host — это DNS-имя или IP-адрес ресурса;
port — необязательная часть формата, указывающая порт соединения примени-
236
тельно к стеку протоколов TCP/IP;
path — это относительный адрес ресурса в пределах файловой системы сервера, использующий разделительный знак «/»;
queryString — необязательной список параметров, представленных в форме «имя=значение», где разделительным символом между такими парами является знак «&»;
fragment — это указатель на конкретное место в документе.
Указанный формат URI соответствует методу GET протокола HTTP, используемого в классических интерпретациях Web-технологий.
Обратите внимание, что это всего лишь один из методов протокола HTTP, который способен полностью отображаться в адресной строке браузеров. Это создает впечатление простоты понимания самой адресации, что пропагандируется Роем Филдингом, но реально применяется только в простейших запросах и то — на английском языке.
С другой стороны, сам адрес не обязательно нужно отображать на HTMLстраницах, читаемых пользователями сервисов. Этот адрес может быть скрыт и заменен подходящими именами, характеризующими ресурс на национальных языках пользователей Интернет. Такой подход широко используется на практике, что подчеркивает хорошую адаптируемость стиля REST.
Представления — это характеристики форматов тех сущностей, которые адресуются с помощью URI.
Компьютерные технологии, включая технологии WEB, разработали множество форматов представления информации. В настоящее время, общепринятым способом обозначения различных представлений являются MIME-типы.
MIME (Multipurpose Internet Mail Extensions) — это многоцелевые расширения интернет-почты, ставшие стандартом, описывающим спецификации для кодирования информации и форматирования сообщений. Базовый набор таких спецификаций определен в ряде документов: RFC 2045, RFC 2046,
RFC 4288, RFC 4289 и RFC 4855.
Официальный список всех MIME-типов публикуется Администрацией адресного пространства Интернет, сокращенно обозначаемого IANA (Internet Assigned Numbers Authority).
Адресуемость — основной принцип проектирования Web-служб в стиле RESTful.
Идея адресуемости — достаточно проста. Если меется сетевой объект, с которым работает потребитель сервиса, то такая сущность должна иметь кон-
237