SOAP vs RESTful
Обычно при сравнении SOAP- и RESTful-сервисов заводят разговор о том, что мол "ну SOAP же тяжелый протокол, а REST-легкий, это всем известно". Но что тяжелого в SOAP-запросе? Пустой SOAP-запрос с заголовком выглядит следующим образом:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header/> <soapenv:Body> </soapenv:Body> </soapenv:Envelope>
Данный запрос занимает всего 158 байт. Говорить о том, что что-то тяжелое только потому что оно на 158 байт длиннее чего-то "легкого" несерьезно. Естественно, что различия между данными подходами гораздо глубже.
Принципиальное отличие между SOAP- и RESTful-сервисами заключается в том, что при SOAP-подходе мы оперируем множеством методов и у нас не существует понятия единого интерфейса, а в случае RESTful-подхода такой единый интерфейс есть и его методы однозначно отображаются на методы HTTP-протокола (в случае использования данного протокола в качестве транспорта). Речь идет о следующем. Интерфейс SOAP-сервиса описывается с помощью WSDL-документа. При этом у каждого сервиса он уникален. Интерфейс может содержать столько методов, сколько необходимо. Собственно пресловутая сложность использования SOAP заключается именно в этом: нужен WSDL, который к тому же необходимо разобрать и разработать обертки для всех его методов, способные интерпретировать SOAP-запросы и формировать SOAP-ответы. В случае же RESTful-подхода интерфейс всегда известен и описывается аббревиатурой CRUD - Create, Read, Update, Delete. При использовании в качестве транспорта HTTP данные операции отображаются на методы данного протокола: POST, GET, PUT, DELETE, соответственно. Сами же сущности, над которыми выполняются данные операции, однозначно идентифицируются с помощью Uniform Resource Identifiers (URI).
Продемонстрируем изложенное выше на примере сервиса работы с банковским счетом. Предположим, что интерфейс данного сервиса должен поддерживать следующие операции: просмотр баланса по номеру счета, снятие денег со счета и внесение денег на счет. При использовании SOAP-подхода интерфейс будет содержать следующие методы:
- getActualBalance(String number);
- widthraw(String number, Money amount);
- deposit(String number, Money amount).
При использовании же RESTful-сервисов ситуаций совершенно иная. У нас есть всего четыре операции над каждой сущностью: создать, изменить, получить и удалить. Применительно к банковскому счету мы можем запросить баланс с помощью операции GET, используя в качестве URI ссылку, содержащую идентификатор счета. Но у нас нет методов снять деньги со счета или внести деньги на счет. Впрочем, мы можем рассматривать данные операции как создание некой транзакции по перемещению денег. Пусть у нас будет сущность "транзакция", содержащая поля "номер счета" и "сумма", которая может быть отрицательная при снятии денег. Мы можем создавать данные транзакции с помощью метода POST. В итоге наш интерфейс будет выглядеть следующим образом:
- GET /bank/account?number=...;
- POST /bank/account/transactions.
Помимо различия в определении интерфейсов сервисов существуют так же и важные различия в реализации. Их можно рассматривать как преимущества одного из подходов над другим.
Технология веб-сервисов, сердцем которой является SOAP, существует уже более десяти лет. За это время было разработано множество стандартов, существенно облегчающих жизнь разработчикам. Речь идет о так называемых WS-*-стандартах. Наиболее используемыми стандартами являются WS-Addressing, применяемый для разделения маршрутизации на транспортном и прикладном уровнях сетевой модели OSI и позволяющий строить асинхронные веб-сервисы. WS-Security - средство для декларативного управления безопасностью на уровне сообщений. С помощью данного стандарта можно настроить шифрование как всего сообщения, так и отдельных его частей, а так же вставить в него электронную цифровую подпись, тем самым гарантировать целостность и неотрекаемость. WS-ReliableMessaging - стандарт, обеспечивающий гарантированную доставку сообщений. Данный стандарт позволяет разработчикам абстрагироваться от работы с очередями сообщений, сконцентрировавшись на логике сервиса. WS-AtomicTransaction - стандарт, позволяющий осуществлять распределенные транзакции, в которых участвуют клиент и сервис. Распределенные транзакции позволяют обеспечить целостность данных в нескольких приложениях. Стоит отметить, что поддержка данных стандартов со стороны производителей программного обеспечения с каждым годом улучается, что является важным аргументом в пользу SOAP-сервисов.
Другой сильной стороной SOAP является независимость от транспорта. При интеграции корпоративных приложений успешно используется как SOAP over HTTP, так и SOAP over JMS.
Сильной стороной RESTful-сервисов является независимость от формы представления данных. Разработчик не связан необходимостью использовать SOAP-протокол и может выбрать тот формат передачи данных, который ему нужен. Не совсем верно передавать XML, если клиентом выступает браузер с поддержкой JavaScript. Гораздо лучше в таком случае передавать данные в формате JSON, который легко преобразуется в JavaScript-объекты путем вызова единственного метода eval(). Да и места данные в формате JSON занимают меньше, что при передаче по сети может быть важно.
Можно настроить RESTful-сервис таким образом, чтобы он оперировал данными в формате, требуемом для приложения. Многие популярные сервисы так и делают, например Twitter может отдавать данные как в XML, так и в JSON. Для указания требуемого формата используется URI, хотя это и не совсем верно с точки зрения архитектурного стиля REST - URI должен адресовать сам ресурс, а не служить для выбора формата его представления. При отправке HTTP-запроса для выбора предпочтительного формата представления можно использовать заголовок Accept.
Однако, за свободу в выборе формата представления данных приходится платить. Прежде всего сложностью в реализации стандартов для обеспечения безопасности, транзакционности, маршрутизации и гарантированной доставки. Все стандарты WS-* приспособлены для использования SOAP в качестве формата представления данных, поэтому для RESTful-сервисов приходится придумывать свои подходы. Работы в данном направлении идут, но кто знает, может быть со временем это сделает REST таким же "тяжелым" как SOAP? К тому же любая технология не лишена глобального недостатка: "это придумали не мы". Возможно уже завтра "тяжелым" объявят REST, а на смену ему придет новая серебряная пуля от маркетологов.
Комментариев нет:
Отправить комментарий