SOAP — это протокол, по которому веб-сервисы взаимодействуют друг с другом или с клиентами. Название происходит от сокращения Simple Object Access Protocol («простой протокол доступа к объектам»). SOAP API — это веб-сервис, использующий протокол SOAP для обмена сообщениями между серверами и клиентами. При этом сообщения должны быть написаны на языке XML в соответствии со строгими стандартами, иначе сервер вернет ошибку.
Появление, развитие и актуальность SOAP API
Протокол SOAP был представлен в 1998 году и быстро стал одним из главных стандартов веб-служб, когда Microsoft продвигала платформу .NET, приложения которой взаимодействовали с помощью SOAP API. Сейчас протокол и API уступают по популярности архитектурному стилю REST. Но веб-приложения, использующие SOAP API, все еще пользуются спросом, особенно в банковском и телекоммуникационном секторах.
Особенности SOAP API
SOAP может использоваться с протоколами SMTP, FTP, HTTP, HTTPS. Чаще всего — с HTTP как с наиболее универсальным: его поддерживают все браузеры и серверы. Корректное SOAP-сообщение состоит из нескольких структурных элементов: Envelope, Header, Body и Fault.
Envelope («конверт»). Это корневой элемент. Определяет XML-документ как сообщение SOAP с помощью пространства имен xmlns_soap=»http://www.w3.org/2003/05/soap-envelope/». Если в определении будет указан другой адрес, сервер вернет ошибку.
Header («заголовок»). Включает в себя атрибуты сообщения, связанные с конкретным приложением (аутентификация, проведение платежей и так далее). В заголовке могут использоваться три атрибута, которые указывают, как принимающая сторона должна обрабатывать сообщение, — mustUnderstand, actor и encodingStyle. Значение mustUnderstand — 1 или 0 — говорит принимающему приложению о том, следует ли распознавать заголовок в обязательном или опциональном порядке. Атрибут actor задает конкретную конечную точку для сообщения. Атрибут encodingStyle устанавливает специфическую кодировку для элемента. По умолчанию SOAP-сообщение не имеет определенной кодировки.
Body («тело»). Сообщение, которое передает веб-приложение. Может содержать запрос к серверу или ответ от него. Пример сообщения, которое запрашивает стоимость ноутбука в онлайн-магазине:
<?xml version="1.0"?> <soap:Envelope xmlns_soap="http://www.w3.org/2003/05/soap-envelope/" soap_encodingStyle="http://www.w3.org/2003/05/soap-encoding"> <soap:Body> <m:GetPrice xmlns_m="https://online-shop.ru/prices"> <m:Item>Dell Vostro 3515-5371</m:Item> </m:GetPrice> </soap:Body> </soap:Envelope>
Пример ответа сервера онлайн-магазина:
<?xml version="1.0"?> <soap:Envelope xmlns_soap="http://www.w3.org/2003/05/soap-envelope/" soap_encodingStyle="http://www.w3.org/2003/05/soap-encoding"> <soap:Body> <m:GetPriceResponse xmlns_m="https://online-shop.ru/prices"> <m:Price>37299</m:Price> </m:GetPriceResponse> </soap:Body> </soap:Envelope>
Fault («ошибка»). Опциональный элемент. Передает уведомление об ошибках, если они возникли в ходе обработки сообщения. Может содержать вложенные элементы, которые проясняют причину возникновения ошибки:
- faultcode — код неполадки;
- faultstring — «человекопонятное» описание проблемы;
- faultactor — информация о программном компоненте, который вызвал ошибку;
- detail — дополнительные сведения о месте возникновения неполадки.
Отличия SOAP от REST
SOAP — протокол, а REST — архитектурный стиль, набор правил по написанию кода. REST был представлен в 2000 году. К этому времени недостатки SOAP были очевидны:
- объемные сообщения;
- поддержка только одного формата — XML;
- схема работы по принципу «один запрос — один ответ»;
- смена описания веб-сервиса может нарушить работу клиента.
Разработчик стиля REST Рой Филдинг учел недостатки SOAP. REST поддерживает несколько форматов помимо XML: JSON, TXT, CSV, HTML. Вместо создания громоздкой структуры XML-запросов при использовании REST чаще всего можно передать нужный URL. Эти особенности делают стиль REST простым и понятным, а приложения и веб-сервисы, использующие его, отличаются высокой производительностью и легко масштабируются.
Пример простого URL-запроса, возвращающего результаты поиска по ключевому слову DNA («ДНК»), можно посмотреть в международной базе научных статей.
Несмотря на простоту использования, у REST есть ряд недостатков, которые отсутствуют у SOAP:
- при использовании REST сложнее обеспечить безопасность конфиденциальных данных;
- трудности с проведением операций, которым необходимо сохранение состояния. Как, например, в случае с корзиной в онлайн-магазине, которая должна сохранять добавленные товары до момента оплаты.
Основные различия SOAP и REST API мы собрали в таблице для большей наглядности:
| Особенности | SOAP API | REST API |
|---|---|---|
| Тип протокола | SOAP является протоколом сообщений. | REST является архитектурным стилем. |
| Протокол обмена данными | XML | Различные форматы, чаще всего JSON. |
| Транспортный протокол | Может использовать разные транспортные протоколы, но чаще всего использует HTTP, SMTP, TCP и т. д. | Использует преимущественно HTTP. |
| WS-* стандарты | SOAP поддерживает стандарты WS-Security, WS-ReliableMessaging, WS-AtomicTransaction и другие. | REST не определяет стандарты безопасности и надежности. Но может использовать дополнительные стандарты, если необходимо. |
| Stateful / Stateless | Может быть как stateful, так и stateless. | RESTful API обычно stateless. |
| Разработка | Более сложная разработка и более объемный размер сообщений из-за XML. | Проще разработка и более легкий размер сообщений благодаря JSON и другим легковесным форматам. |
| Кэширование | Обычно имеет ограниченную поддержку кэширования. | Поддерживает хорошее кэширование на уровне HTTP. |
| Модель безопасности | Следует стандартам WS-Security для безопасности. | Использует HTTPS для обеспечения безопасности. Также может использовать токены авторизации, как OAuth. |
| Поддержка | Имеет более широкую поддержку в старых системах и в предприятии. | Популярен в веб-приложениях и мобильных приложениях. Широко используется в RESTful веб-сервисах. |
В каких случаях используют SOAP
- Асинхронная обработка и последующий вызов. Стандарт SOAP 1.2 обеспечивает клиенту гарантированный уровень надежности и безопасности.
- Формальное средство коммуникации. Если клиент и сервер имеют соглашение о формате обмена, то SOAP 1.2 предоставляет жесткие спецификации для такого типа взаимодействия. Пример — сайт онлайн-покупок, на котором пользователи добавляют товары в корзину перед оплатой. Предположим, что есть веб-служба, которая выполняет окончательный платеж. Может быть достигнуто соглашение, что веб-сервис будет принимать только название товара, цену за единицу и количество. Если сценарий существует, лучше использовать протокол SOAP.
- Операции с состоянием. Если приложение требует, чтобы состояние сохранялось от одного запроса к другому, то стандарт SOAP 1.2 предоставляет структуру для поддержки таких требований.
0 комментариев