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

В качестве примера, Рой Филдинг указывает на так называемый «сетевой серфинг», когда нужная информация находится пользователем посредством нескольких «кликов» устройством мыши. Очвидно, что для приложений, которые требуют иных действий, технология REST не дает столь убедительного эффекта.

6.1.2Протокол HTTP

Вотличие от технологии SOAP, RESTful ориентирован на использование только протокола HTTP.

Технология RESTful ориентируется на максимальное использование возможностей протокола HTTP, а также — на непосредственное представление информации в браузерах пользователей.

Как было показано в начале текущей главы, идейная основа CRUD, зародившаяся в недрах централизованного использования баз данных, управляемых СУБД, легко проецируется на четыре метода доступа к Web-серверам по протоколу HTTP. Это — методы: POST, GET, PUT и DELETE. И хотя большинство браузеров поддерживают только методы GET и POST, сами Web-технологии допускают использование еще четырех типов запросов:

1)запрос HEAD — идентичен запросу GET, но не возвращает в ответ тело сообщения;

2)запрос TRACE — отражает полученный запрос назад клиенту, позволяя проверять, какую информацию добавляет к запросу или изменяет промежуточный сервер, прокси-сервер или брандмауэр;

3)запрос OPTIONS — выполняет запрос информации о возможностях коммуникации для той цепочки запросов/ответов, на которую указывает данный URI;

4)запрос CONNECT — используется с прокси-серверами для динамического переключения на работу в режиме туннеля.

Язык HTML и браузеры обеспечивают запросы только в виде методов GET и POST.

Возможности браузеров и языка HTML существенно ограничивают пря-

238

мое использование браузеров в реализации технологии REST. Возможно в будущем эта ситуация изменится, но в настоящее время полное применение стиля REST возможно только через Proxy-серверы или серверы приложений. Таким образом, технология RESTful — гораздо шире узких ограничений языка HTML и протокол HTTP предоставляет ей дополнительные свойства, которые уже реализованы или будут реализованы в современных браузерах. Рассмотрим указанные возможности.

Согласование содержимого — это механизм автоматического определения необходимого представления при наличии нескольких разнотипных вариантов, использующий заголовки HTTP-запросов Accept, Accept-Charset, AcceptEncoding, Accept-Language и User-Agent, как это показано в таблице 6.1.

Таблица 6.1 — Базовый набор значений заголовков [17]

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

Типы содержимого — это MIME-типы, записываемые в полях заголовков

Content-Type и Accept, например:

а) text/plain — используется по умолчанию, им записываются простые текстовые сообщения;

б) text/html — базовый тип, применяемый в браузерах и информирующий пользовательский агент о получении Web-страницы на языке HTML;

в) image/gif, image/jpeg, image/png — обобщающий тип, соответствующий

239

изображениям нескольких типов и требующий соответствующего устройства отображения для просмотра информации;

г) text/xml, application/xml — формат, используемый для обмена XML-сооб- щениями;

д) application/json — «легковесный» текстовый формат для обмена данными, не зависящий от конкретного языка программирования.

Безусловно, количество возможных MIME-типов — значительно шире, что требует изучения документов RFC, указанных в предыдущем пункте.

Важнейшей частью протокола HTTP являются возвращаемые сервером коды состояния.

Коды состояния — это трехзначные целые числа, которые описывают контекст пришедшего ответа. Первая цифра кода состояния указывает на один из классов ответа:

а) 1xx — информационный: запрос получен, процесс продолжает работу;

б) 2xx — успех: действие было успешно получено, интерпретировано и принято;

в) 3xx — перенаправление: необходимо выполнить дополнительные действия для полного удовлетворения запроса;

г) 4xx — клиентская ошибка: запрос содержит ошибочный синтаксис или не может быть удовлетворен;

д) 5xx — серверная ошибка: серверу не удалось выполнить запрос.

Полный список кодов возврата — достаточно большой. Его можно найти в источнике [27].

Прямой стиль адресации Web-служб — это стиль адресации ресурса, который позволяет обеспечивать над ним различные операции из разряда стандартного набора CRUD.

Поясним данное положение штатным примером нашей дисциплины, который демонстрирует сервис для работы со списком записей Letter. С помощью стандартного набора CRUD мы можем: получить весь список записей, получить отдельную запись по ее номеру, а также — добавить новую запись, модифицировать или удалить любую запись по ее номеру.

Теперь, если сервис реализован в проекте lab9 на хосте localhost и порту 8080, то адрес http://localhost:8080/lab9/letter можно понимать в двух вариантах:

1)для метода GET — прочитать все записи;

2)для метода POST — добавить новую запись.

Если к указанному адресу добавить целое число, которое интерпретиро-

240

вать как номер записи, например, http://localhost:8080/lab9/letter/72, то добавляются следующие три интерпретации:

1)для метода GET — прочитать запись с номером 72;

2)для метода PUT — модифицировать запись с номером 72;

3)для метода DELETE — удалить запись с номером 72.

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

6.1.3Языки WADL и HAL

Вавгусте 2009, компания Sun Microsystems предложила для моделирования ресурсов Web-сервисов язык WADL.

WADL (Web Application Description Language) — это машинно-читаемое XML-описание для Web-приложений, которое — подобно языку WSDL для SOAP, но использует только протокол HTTP.

Язык был предложен Всемирному консорциуму W3C, но не получил широкого распространения, возможно по причине не очень большой любви к языку XML. В любом случае, он еще не стандартизирован и W3C не имеет на него никаких планов.

Как отмечено ранее, REST является архитектурным стилем разработки Web-приложений, что накладывает на проектные решения дополнительные ограничения. Одним из таких архитектурных ограничений на REST-приложе- ния является проект HATEOAS.

HATEOAS — это ограничение, требующее чтобы сервер обеспечивал

взаимодействие с клиентом посредством динамического доступа через гипермедиа, что означает доступ к ресурсам через гиперссылки в гипертексте.

В настоящее время не существует универсального формата для предоставления ссылок между ресурсами.

Не вдаваясь в детальный анализ представленного выше утверждения, отметим, что существует два популярных формата представления ссылок в REST гипермедиа сервисах:

а) RFC 5988 — документ, описывающий спецификации типов Web-ссылок [28];

б) JSON Hypermedia API Language — описание языка HAL, использующего гиперссылки в формате представления JSON [29].

241