[Документация Yandex Cloud](../index.md) > [Облачная терминология](index.md) > Сети и доставка контента > SOAP
# Протокол SOAP: что это и как работает
SOAP — высокоуровневый протокол обмена информацией между веб-сервисом и клиентом. Сообщения передаются в формате XML над протоколами прикладного уровня, такими как [HTTPS](ssl-certificate.md) и HTTP. Например, с помощью SOAP приложение может запросить у метеорологического сайта прогноз погоды, а у банка — курсы валют.
SOAP характеризуют три принципа:
* _Расширяемость_ — поддерживает интеграцию с большинством существующих механизмов безопасности и передачи данных.
* _Нейтральность_ — работает с любым протоколом прикладного уровня.
* _Независимость_ — поддерживает любую модель разработки.
## История возникновения {#history}
Прототипом SOAP можно считать протокол [XML-RPC](https://ru.wikipedia.org/wiki/XML-RPC), созданный в 1998 году. Однако компания Microsoft сочла его функциональность недостаточной и доработала существующее решение. Так появилась первая версия SOAP.
Статус веб-стандарта получила только версия 1.2, которая была значительно изменена. Если изначально под аббревиатурой понимался «простой протокол доступа к объектам» (Simple Object Access Protocol), то с версии 1.2 SOAP вообще никак не расшифровывается. Так разработчики подчеркнули, что протокол универсальный, а не только для «доступа к объектам».
SOAP довольно быстро стал основой для множества веб-сервисов и корпоративных систем, хотя сегодня он уступает по популярности [REST](#rest).
## Структура {#structure}
SOAP характеризуется XML-форматом, состоящим из трех элементов:
* Конверт (`Envelope`) — указывает на начало и конец сообщения, а также определяет пространство имен, использованное в документе.
* Заголовок (`Header`) — содержит дополнительные атрибуты сообщения, такие как данные аутентификации или настройки транзакции. Необязательный элемент.
* Тело (`Body`) — само сообщение, то есть запрос или ответ.
Если при обмене сообщениями произошла ошибка (например, неверные данные аутентификации), то вернется также компонент `Fault`, который содержит информацию о ней.
## Принцип работы {#how-work}
Обмен SOAP-сообщениями происходит следующим образом:
1. Клиент отправляет запрос в формате XML на SOAP-эндпоинт приложения.
1. Сервер проверяет корректность запроса по конверту и заголовку, обрабатывает метаданные.
1. Сервер извлекает содержимое тела запроса и обрабатывает его в соответствии со своей внутренней логикой.
1. Сервер формирует ответное SOAP-сообщение с необходимой клиенту информацией.
1. Клиент получает сообщение, анализирует его и извлекает запрошенную информацию. В случае ошибки действует согласно заданной логике, например, отображает сообщение об ошибке пользователю.
Обычно процесс также включает работу [механизмов безопасности](#safety), таких как аутентификация, расшифровка сообщения и проверка подписи.
{% cut "Пример запроса и ответа" %}
Запрос курса USD на 17 октября 2025 года у банка:
```xml
api_user
password
USD
2025-10-17
```
Ответ:
```xml
171025
2025-10-17T14:11:00Z
0.79
USD
2025-10-17
```
{% endcut %}
## Безопасность {#safety}
SOAP использует собственный стандарт обеспечения безопасности — _WS-Security_. Он предоставляет несколько механизмов, работающих на уровне приложения:
* **Подпись** — обеспечивает целостность, аутентичность сообщений и легитимность отправителя.
* **Шифрование** — защищает содержимое сообщений от несанкционированного доступа.
* **Аутентификация** — подтверждает личность пользователя с помощью токенов.
Сами по себе эти механизмы не являются самодостаточной системой безопасности, но служат фундаментом для ее реализации. WS-Security можно использовать совместно с другими, более надежными средствами, например [SSO](sso.md) и [TLS](tls.md).
### Проблемы безопасности {#issues}
Риски и угрозы безопасности при работе с SOAP:
* При недостаточной или неправильной настройке протокол уязвим для стандартных атак: инъекций, повторного воспроизведения сообщений, перехвата информации и других. Для устранения всех уязвимостей нужна высокая квалификация.
* При регулярном обмене сообщениями следует ограничить защиту до необходимого минимума, иначе она значительно замедлит процесс. Например, без необходимости не рекомендуется совместно использовать и шифрование, и подпись.
* Использование SOAP одновременно с несколькими другими XML-схемами, такими как [SAML](sso.md#protocols), может привести к проблемам совместимости на уровне библиотек и дополнительным сложностям в управлении безопасностью.
## Альтернативы {#alternatives}
Для некоторых приложений использование SOAP — не самый оптимальный выбор из-за высоких затрат ресурсов. Формат XML предполагает множество дополнительных символов, что утяжеляет сообщение и замедляет передачу. Если для вашего приложения это критически важно, ознакомьтесь с другими средствами.
### REST {#rest}
Чаще всего SOAP сравнивают с [REST](rest-api.md). Это архитектурный стиль, который предполагает обмен сообщениями без сохранения состояния (данные об участниках и история сообщений не сохраняются) и не зависит от технологий, используемых сервером и клиентом. REST напрямую использует протокол HTTP и не ограничен только одним возможным форматом данных. Сравним методы подробнее:
Аспект | SOAP | REST
-------|------|-----
Форматы | XML | XML, JSON, CSV, HTML, Atom, RSS и другие
Сохранение состояния | Опционально | Не поддерживается
Транспортный протокол | Любой | HTTP
Стандарты безопасности | [WS-Security](#safety), поддерживает другие технологии | Не имеет собственной системы безопасности, но поддерживает HTTPS и аутентификацию с помощью токенов
Производительность | Низкая | Высокая
Сложность настройки | Сложная | Простая
Сообщество | Небольшое | Обширное
Где используется | Корпоративные системы, legacy-приложения | Мобильные и веб-приложения
### Другие альтернативы {#other}
В зависимости от нужд вашего приложения вы также можете рассмотреть другие способы обмена данными:
* [gRPC](grpc.md) — высокопроизводительный протокол на основе HTTP/2, использующий бинарный формат передачи данных. Часто реализуется в средах, где ресурсы ограничены, например, в интернете вещей и микросервисах.
* [GraphQL](https://ru.wikipedia.org/wiki/GraphQL) — поддерживает декларативную выборку данных через один эндпоинт. Результаты передаются в виде абстрактного типа данных (графа) и чаще всего оборачиваются в формат JSON. Используется в средах, где важна гибкость передаваемых данных, например, когда в одном сообщении надо передать и медиаконтент, и текст.
* [WebSockets](https://ru.wikipedia.org/wiki/WebSocket) — двусторонняя связь в реальном времени. Используется для непрерывного обмена данными, как в случае чатов.
* XML-RPC — предшественник SOAP, сохраняющий популярность благодаря облегченному XML-формату. Подходит для вызовов простых удаленных процедур.
## Примеры использования {#examples}
Громоздкий синтаксис XML иногда может быть и преимуществом. При правильной настройке протокол имеет повышенную безопасность, позволяет легче обнаружить ошибки и избежать проблем с совместимостью. Рассмотрим примеры сценариев, в которых SOAP может быть оптимальным выбором:
* **Электронная коммерция** — SOAP популярен для транзакционных операций с сохранением состояния и повышенными требованиями к безопасности.
* **Медицинские приложения** — протокол обеспечивает высокий уровень конфиденциальности, что важно для передачи чувствительных медицинских данных.
* **Корпоративные системы** — SOAP легко интегрируется с любыми, непохожими друг на друга системами и устаревшими приложениями, открывая возможности для масштабирования.
* **Научные приложения** — протокол удобен для обмена точными данными с повышенными требованиями к формату.