Веб-службы REST - Введение u. Сравнение с SOAP

1. абстрактный
2. введение
3. 1 пример приложения REST
4. 1.1 Заказать - или инициировать операцию на сервере
5. 1.2 Создание новых ресурсов
6. 1.3 Удаление ресурсов
7. 2 Мир ОТДЫХА
8. 2.2 Представления
9. 2.3 Методы
10. 2.4 Новости
11. 2.5 Статус и сессия
12. 3 ОТДЫХ и безопасность
13. 4 функции приложения REST
14. 5 преимуществ ОТДЫХА
15. 5.2 Подключение внешних систем
16. 5.3 Независимо устанавливаемые компоненты
17. 5.4 Состав услуг
18. 6 Сравнение REST и SOAP
19. 6.1 Прокси-сервер
20. 6.2 Общий интерфейс
21. 6.3 стандарты
22. 7 Как создать REST-приложение ...
23. 8 ОТДЫХ и семантическая паутина
24. 9 границ REST
25. 10 поддержка инструмента
26. 11 государственных служб REST
27. 12 вывод

Введение Автор:

Томас Байер
Ориентация в Objects GmbH

Дата:

ноябрь 2002

абстрактный

Веб-сервисы обычно связаны с SOAP или XML-RPC. REpresentational State Transfer или REST, архитектурный стиль, также могут использоваться для реализации веб-сервисов. Эта статья описывает REST в качестве примера и объясняет такие аспекты, как безопасность и масштабируемость. Отличия промежуточного программного обеспечения RPC показаны сравнением между REST и SOAP.

введение

Помимо SOAP и XML-RPC, существует еще одна альтернатива для реализации веб-сервисов. Томас Рой Филдинг в своей диссертации описывает архитектурный стиль, который он называет REpresentational State Transfer Architecture или REST для краткости.

REST основан на принципах, используемых в крупнейшем распределенном приложении - World Wide Web. Всемирная паутина сама по себе является гигантским приложением REST, многие поисковые системы, магазины или системы бронирования уже доступны без веб-служб на основе REST.

REpresentational State Transfer Architecture - это модель архитектуры, которая описывает, как должна работать сеть. Модель послужит руководством и справкой для будущих расширений.

ОТДЫХ не является продуктом или стандартом. REST описывает, как веб-стандарты могут быть использованы на веб-ярмарке.

1 пример приложения REST

Интернет-магазин должен служить примером приложения RESTful. В приложении есть клиенты, которые могут забрать вещи в корзинах.

Каждый отдельный объект приложения, такой как статья или клиент, представляет ресурс, к которому можно получить внешний доступ через URL-адрес. В примере приложения для доступа к корзине покупок с номером 5873 можно использовать следующий вызов.

GET / корзина / 5873

Пример 1: Позвоните в корзину № 5873

Как отображается результат запроса, не указано в REST. Должно быть общее понимание между клиентом и сервером о значении представления. Использование XML облегчает понимание представления как для людей, так и для машин. Результат запроса корзины покупок может выглядеть так:

HTTP / 1.1 200 OK Тип содержимого: text / xml <? Xml version = "1.0"?> <Корзина xmlns: xlink = "http://www.w3.org/1999/xlink"> <клиент xlink: href = "http://shop.oio.de/kunde/5873"> 5873 </ customer> <position nr = "1" set = "5"> <article xlink: href = "http://shop.oio.de / article / 4501 "nr =" 4501 "> <description> Lollipop </ description> </ article> </ position> <position nr =" 2 "set =" 2 "> <article xlink: href =" http: / /shop.oio.de/artikel/5860 "nr =" 5860 "> <description> Чай Эрл Грей </ description> </ article> </ position> </ cart>

Пример 2: Представление корзины товаров

Как показано в листинге 1, ответ сервера включает в себя документ XML, который по своей природе совместим со многими стандартами XML и может быть дополнительно обработан. Ответ может быть преобразован, например, в HTML, SVG или PDF с помощью преобразования XSLT. Документ может ссылаться на другие ресурсы с XLink и XPointer. XPath или XQuery можно использовать для формулирования запросов к документу.

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

GET / article / 5860

Пример 3: изменение статьи с помощью XLink

С каждым документом клиент может углубиться в приложение. Точкой входа является один URL. Идея гипертекстовых документов, известных из Интернета, передается веб-сервисам. Рисунок 1 и Рисунок 1 показывают график, охватывающий ограничение. Клиент может увязнуть в ссылках от ресурса к ресурсу.

Рисунок 1: Навигация по ссылкам a. HTTP GET

1.1 Заказать - или инициировать операцию на сервере

Конфеты не должны отсутствовать в хорошем черном чае. Порядок должен быть расширен этой важной статьей. Предположим, что сахар Канди имеет номер статьи 961. Метод POST используется для добавления дочернего ресурса или логики вызова, которая вызывает изменение состояния на сервере. Следующий запрос POST добавляет товарный сахар с номером товара 961 в корзину товаров.

POST / корзина / 5873 номер позиции = 961

Пример 4: запрос POST

1.2 Создание новых ресурсов

Для создания новых ресурсов, которые не назначены другим ресурсам, можно использовать метод HTTP PUT.

PUT / статья <article> <описание-краткое> чай ройбуш </ description-short> <описание> изысканный намибийский чай ройбуш </ description> <цена> 2,80 </ цена> <единица> 100 г </ единица> </ статьи>

Пример 5: запрос PUT

Результат вызова PUT возвращает через HTTP URL-адрес недавно созданной статьи. Создание создает новый объект, который может использоваться другими клиентами.

HTTP / 1.1 201 OK Content-Type: text / xml; Длина контента: 30 http://shop.oio.de/artikel/6005

Пример 6: Ответ на PUT

В листинге 3. показан ответ сервера. Код состояния HTTP 201 означает «создан», то есть создан новый ресурс. В теле сообщения есть ссылка на недавно созданный ресурс, чай ройбуш.

1.3 Удаление ресурсов

Вновь созданный ресурс можно удалить с помощью следующего запроса HTTP DELETE.

УДАЛИТЬ / item / 6005

Пример 7: удаление ресурсов

В примере показано, как работать с ресурсами, методами HTTP и URI. В следующих разделах будут углублены используемые концепции.

2 Мир ОТДЫХА

2.1 Ресурсы

Веб-страницы, изображения и CGI-скрипты или сервлеты представляют собой ресурсы, к которым можно обращаться и обращаться через URL-адреса. Веб-приложение представляет собой набор ресурсов. С помощью HTTP сообщения можно отправлять на ресурсы, например, вызывая страницу в браузере.

Прямое манипулирование ресурсом не предусмотрено. Каждый доступ осуществляется косвенно через URI, назначенный Resouce.

Рисунок 2: Маршрутизация сообщений REST

Семантика протокола HTTP была принята в REST. Методы HTTP GET, PUT, POST и DELETE играют центральную роль в REST. Они представляют собой «глаголы», которые можно применять к «основным словам» или ресурсам. При таком ограниченном количестве четырех методов все приложения должны быть общими.

2.2 Представления

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

Причина использования термина REpresentational State Transfer становится понятной из следующего сценария. Веб-браузер запрашивает страницу или, в более общем случае, ресурс через URL-адрес. HTML-документ, представляющий представление ресурса, передается с сервера на клиент. HTML-документ может содержать ссылки, указывающие на дополнительные ресурсы в Интернете. Если клиент переходит на новую страницу, он меняет состояние, меняет состояние или переходит в новое состояние. Представительства осуществляют переход из одного статуса в другой.

2.3 Методы

Интерфейс REST является универсальным. Нет необходимости знать соглашения протокола для взаимодействия клиента и сервера. В следующем списке описывается значение методов HTTP, используемых REST.

• GET: Get запрашивает представление ресурса. Запросы должны быть без побочных эффектов. GET запросы можно отправлять так часто, как вам нравится. Вы не можете привлечь клиента к ответственности за его влияние. Д. ч. GET может быть отправлено без колебаний.

• POST: POST может добавить что-то к ресурсу. Например, товар можно добавить в корзину. POST не свободен от побочных эффектов. Например, вызов POST может изменить поля в базе данных или запустить процессы на сервере.

• PUT: новые ресурсы можно создавать с помощью PUT или содержимое существующих ресурсов можно заменить на PUT.

• УДАЛИТЬ: ресурсы могут быть удалены с помощью УДАЛИТЬ.

Каждый ресурс REST имеет универсальный интерфейс через HTTP-методы GET, POST, PUT и DELETE. Этими четырьмя методами можно охватить большинство случаев использования. Многие приложения, использующие SQL, также используют только общие команды SELECT, INSERT, UPDATE и DELETE.

2.4 Новости

Все типы документов могут быть перенесены в приложения REST. Например, файлы HTML, GIF и PDF используются в Интернете. Для передачи структурированных данных подходит XML. Документы XML могут использовать XLink для ссылок. Кто хочет реализовать приложение с REST, не должен изучать новый формат. Вы можете использовать уже известные форматы.

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

2.5 Статус и сессия

Сервер знает свой статус. Он не интересуется статусом клиента или сессиями со своими клиентами. Клиент управляет своим собственным состоянием, а также определяет порядок, в котором он вызывает различные методы на сервере.

В приложениях REST никаких специальных функций для входа в систему обычно не требуется. Все ресурсы могут быть аутентифицированы и авторизованы с использованием доступных веб-технологий, таких как HTTP и HTTPS.

3 ОТДЫХ и безопасность

Видение CORBA как шины галактического объекта не было реализовано, как предсказывали его сторонники. Причина, в дополнение к сложности CORBA, заключалась в том, что корпоративные и организационные сети все чаще были защищены брандмауэрами. Протокол Core IIOP, используемый CORBA, блокируется большинством брандмауэров.

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

Для существующих брандмауэров и администраторов все сообщения SOAP или XML-RPC выглядят одинаково. Это HTTP-пост. Чтобы понять смысл сообщения, рассмотрим тело SOAP, которое не имеет ничего общего с HTTP и вещами, которые обычно знает администратор или брандмауэр.

Приложение на основе REST использует HTTP-методы и URL-адреса для своих сообщений. Брандмауэры знакомы с HTTP и URL. Вы можете фильтровать по методам и URL-адресам. Например, брандмауэр может ограничить доступ к приложению REST для доступа к чтению, разрешая только запросы GET от внешних пользователей.

Значение сообщения возникает в приложении REST из HTTP-запросов. Журнал доступа веб-сервера показывает, какие действия были выполнены. В журнале в листинге 4 указано, что корзина 6 и статьи 5 и 12 прочитаны. Следующий POST, вероятно, был добавлен в корзину как товар. После этого заказывается корзина покупок и считывается новый заказ.

hermes.oio.de - - [26 / Nov / 2002: 12: 43: 07 +0100] "GET / корзина покупок / 6 HTTP / 1.1" 200 hermes.oio.de - - [26 / Nov / 2002: 12: 43 : 08 +0100] "GET / article / 12 HTTP / 1.1" 200 hermes.oio.de - - [26 / Nov / 2002: 12: 43: 08 +0100] "GET / article / 5 HTTP / 1.1" 200 hermes .oio.de - - [26 / Nov / 2002: 12: 43: 09 +0100] "POST / корзина покупок / 6 HTTP / 1.1" 200 hermes.oio.de - - [26 / Nov / 2002: 12: 43: 13 +0100] "POST / корзина покупок / 6 HTTP / 1.1" 200 hermes.oio.de - - [26 / Nov / 2002: 12: 43: 14 +0100] "GET / order / 3 HTTP / 1.1" 200

Пример 8: Протокол приложения REST

SOAP кодирует все необходимые параметры в сообщении. Администратор брандмауэра имеет небольшое влияние и обычно не учитывается. Существует риск того, что SOAP будет отфильтрован в некоторых установках брандмауэра в будущем. Приложения на основе REST упрощают федерацию администраторов. Вы получаете возможность с вашими ресурсами и инструментами для входа и фильтрации. Таким образом, готовность не блокировать REST намного выше. Общая блокировка REST также невозможна, если доступ к сети полностью не заблокирован.

4 функции приложения REST

Следующие функции отмечают стиль REST.

• Общение происходит по вызову. Клиент активен и запрашивает представление от пассивного сервера или изменяет ресурс.

• Ресурсы, объекты приложения, имеют связанный с ними URI, с которым они могут быть адресованы.

• Представление ресурса может быть запрошено как документ от клиента.

• Представления могут указывать на дополнительные ресурсы, которые, в свою очередь, предоставляют представления, которые в свою очередь могут ссылаться на ресурсы.

• Сервер не отслеживает статус клиента. Каждый запрос к серверу должен включать всю информацию, необходимую для интерпретации запроса.

• Кеши поддерживаются. Сервер может пометить свой ответ как поддерживающий кэш или не поддерживающий кэш.

5 преимуществ ОТДЫХА

5.1 Масштабируемость

Огромный рост Всемирной паутины показал, насколько масштабируются веб-технологии. Миллионы пользователей используют ресурсы, предлагаемые многими тысячами серверов. Прокси и кеши повышают производительность. Такие компоненты, как серверы, прокси-серверы и веб-приложения, могут устанавливаться и обслуживаться индивидуально.

Существует множество форматов от HTML и SVG до AVI. Даже новые форматы могут быть легко добавлены через типы MIME. Размер передаваемых документов варьируется от нескольких байтов до многих мегабайт.

В Интернете файлы cookie и перезапись URL-адресов используются для настройки искусственного сеанса HTTP без сохранения состояния , который является состоянием . В этом пункте REST отклоняется от сети. Взаимодействия в REST не имеют состояния - каждая операция стоит отдельно . Вся необходимая информация содержится в представлениях ресурсов. С HTTP нет границ между приложениями. Отслеживая ссылку, вы можете, не намереваясь, перейти в совершенно другое приложение. Поскольку все взаимодействия не имеют состояния, нет необходимости передавать статус между серверами при переключении с одного сервера на другой. Это положительно влияет на масштабируемость приложения.

5.2 Подключение внешних систем

Ни одно другое приложение не объединяет столько устаревших систем, сколько в Интернете. Различные шлюзы обеспечивают доступ к множеству систем. Детали сторонних систем скрыты за интерфейсами.

5.3 Независимо устанавливаемые компоненты

Компоненты могут быть независимо развернуты в приложении REST. Содержимое отдельных страниц можно также обмениваться в Интернете без необходимости адаптации других страниц. Для очень больших систем, таких как World Wide Web или служба электронной почты в Интернете, независимое развертывание является основным требованием.

5.4 Состав услуг

Отдельные услуги REST могут быть легко использованы вместе. Строго говоря, REST-сервисов нет. Есть только доступные ресурсы. Глобальное и универсальное адресное пространство URI может легко превысить пределы приложения. Документ просто ссылается на ресурс, который находится в другой организации.

6 Сравнение REST и SOAP

SOAP - это промежуточное программное обеспечение RPC [1], которое использует HTTP или SMTP в качестве транспортного протокола и XML в качестве формата сообщения. Для полноты картины следует упомянуть, что документы также можно передавать с использованием SOAP с приложениями .

Доставка сообщений SOAP аналогична работе домашней почты. К корзинам персонала нельзя обращаться напрямую. Все письма доставляются на внутреннюю почту. Внутренняя почта должна открывать письма перед доставкой, а затем на основе содержимого принимает решение, кому сообщение отправлено. В приложении REST корзины напрямую адресуются. В этом отношении спецификация SOAP 1.2 приближает SOAP к REST. В будущем методы также могут быть указаны вне тела.

Сообщения SOAP всегда адресованы конечной точке, которая реализуется маршрутизатором или диспетчером SOAP. Маршрутизаторы SOAP реализованы с помощью сервлета или CGI-скрипта. На рисунке 3 показано, что все вызовы сначала направляются диспетчеру. Каждое сообщение является HTTP POST на тот же адрес.

Рисунок 3: Маршрутизация SOAP-сообщений

SOAP - это комплект для создания протоколов, который позволяет разработчикам разрабатывать свои собственные протоколы приложений. Протокол описывает точную структуру запроса и ответа. Описание запроса и ответа представляет собой жесткую структуру, из которой нелегко вырваться. Если сервер хочет предоставить больше информации, чем раньше, он не может сделать это через существующий интерфейс. Чтобы уже установленные клиенты оставались совместимыми, необходим новый веб-сервис. С помощью REST сервер может предоставлять дополнительную информацию, а интерфейс веб-службы может оставаться неизменным. У SOAP нет возможности постепенно развивать существующие веб-сервисы.

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

6.1 Прокси-сервер

Приложение RESTful состоит из множества URL-адресов, к которым могут обращаться клиенты. Если к приложению REST осуществляется доступ через прокси-сервер, обычный прокси-сервер, такой как популярный Squid, может принять решение на основе URL-адреса, разрешить или запретить доступ. Доступ к каждому объекту может быть зарегистрирован в прокси и веб-сервере. Поскольку все запросы SOAP обычно направляются через URL-адрес, прокси-сервер или веб-сервер не могут принять решение с помощью URL-адреса. Например, в приложениях RESTful доступ ко всем URL-адресам может быть запрещен по следующей схеме:

отрицать http://shop.oio.de/artikel/delete/*

Пример 9: Отказ в доступе к URL

REST позволяет кэшировать вызовы GET. SOAP, с другой стороны, использует только метод POST, который не кэшируется .

6.2 Общий интерфейс

REST предлагает общий интерфейс с методами GET, POST, PUT и DELETE. В SOAP все методы должны быть определены для каждого приложения. Это мешает разработке общих инструментов и сервисов в Интернете.

6.3 стандарты

REST рекомендует использовать установленные стандарты. Например, разработчику доступны следующие «технологии»:

• URI для адресации

• HTTP методы для доступа

• XML, XHTML, HTML, PNG, ... для форматов данных

• MIME типы

Центральными являются стандарты HTTP и URI. Напротив, форматы могут использоваться для форматов представлений. Будущие технологии также могут быть использованы.

Для SOAP ряд стандартов, таких как WSDL, UDDI, WS-Security, WS-Transactions или BPEL4WS, в настоящее время создается исключительно для SOAP. Стандарты REST - это «правильные» веб-стандарты, которые можно использовать для многих целей, а не только для REST.

7 Как создать REST-приложение ...

... или существующее приложение делает RESTful? Распределенные приложения основаны на функциях или методах, которые работают с объектами. Клиент может получить доступ к объектам сервера, используя удаленные методы. Приложение REST делает ваши объекты видимыми снаружи через URI. Бизнес-объекты должны быть доступны через URL и представлены в документе, предпочтительно в формате XML.

Ядро сервера REST ничем не отличается от приложения RPC. Разница заключается в интерфейсе, который принципиально отличается от приложения RPC в REST. REST использует методы HTTP, которые работают с адресуемыми ресурсами URI, а RPC предоставляет компонентный интерфейс со специализированными методами или функциями.

8 ОТДЫХ и семантическая паутина

Для SOAP и REST клиент должен понимать, как интерпретировать сообщения с сервера. С RDF в качестве формата сообщения и соответствующими интерференционными машинами были бы мыслимые клиенты, которые могут учиться во время выполнения. Роджер Л. Костелло пишет в своей презентации « Представительный государственный трансферт» [2]:

... динамическое изучение данных ответов в сочетании с динамическими рассуждениями об обходах ссылок приведет к самоорационализирующимся автоматам. Это следующий шаг в сети!

9 границ REST

REST использует HTTP для транспортировки и передает целые представления объектов клиенту. Для интернет-приложений, которые в любом случае должны ожидать большую задержку, это хорошо. Между специализированными локальными серверами, например между сервером приложений и базой данных, необходимы более эффективные протоколы, такие как CORBA, RMI или DCOM.

Сериализация и десериализация в и из XML не рассматриваются в REST. Программист должен сам позаботиться об этом или использовать XML Binding Framework.

REST - это архитектурный стиль, подходящий для больших приложений с неизвестным количеством пользователей и объектов.

10 поддержка инструмента

REST основан на установленных стандартах, которые уже имеют множество инструментов. REST поддерживает веб-серверы, такие как Apache или IIS, веб-контейнеры, такие как Tomcat, и прокси-серверы, такие как Squid. Специализированные инструменты REST не нужны. Возможно, что библиотеки, фреймворки или инструменты будут поддерживать разработку приложений REST в будущем.

11 государственных служб REST

Уже существует ряд общедоступных веб-сервисов, которые намеренно используют интерфейсы RESTful. Среди наиболее известных - веб-сервисы от Amazon, Google или Meerkat O'Reilly.

Некоторые веб-сервисы, такие как Wiki Webs, по крайней мере частично соответствуют REST.

12 вывод

REST использует только зрелые и стандартизированные стандарты, такие как HTTP или URI, которые были доступны в течение нескольких лет. REST использует идеи Интернета, такие как гипертекст и бесконечное глобальное адресное пространство. Таким образом, веб-службы на основе REST являются реальными веб-службами, а не промежуточным программным обеспечением на основе RPC.

Похожие

Комментарии