SOAP API

SOAP — это протокол, по которому веб-сервисы взаимодействуют друг с другом или с клиентами. Название происходит от сокращения Simple Object Access Protocol («простой протокол доступа к объектам»). SOAP API — это веб-сервис, использующий протокол SOAP для обмена сообщениями между серверами и клиентами. При этом сообщения должны быть написаны на языке XML в соответствии со строгими стандартами, иначе сервер вернет ошибку.

Схема взаимодействия веб-приложений по протоколу SOAP

Появление, развитие и актуальность 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.

Структура SOAP-сообщения

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

  • Асинхронная обработка и последующий вызов. Стандарт SOAP 1.2 обеспечивает клиенту гарантированный уровень надежности и безопасности.
  • Формальное средство коммуникации. Если клиент и сервер имеют соглашение о формате обмена, то SOAP 1.2 предоставляет жесткие спецификации для такого типа взаимодействия. Пример — сайт онлайн-покупок, на котором пользователи добавляют товары в корзину перед оплатой. Предположим, что есть веб-служба, которая выполняет окончательный платеж. Может быть достигнуто соглашение, что веб-сервис будет принимать только название товара, цену за единицу и количество. Если сценарий существует, лучше использовать протокол SOAP.
  • Операции с состоянием. Если приложение требует, чтобы состояние сохранялось от одного запроса к другому, то стандарт SOAP 1.2 предоставляет структуру для поддержки таких требований. 

Освойте новую профессию

(рейтинг: 3.75, голосов: 4)
Добавить комментарий