Спор «REST или SOAP» часто ведут так, будто это две версии одной технологии и одна из них просто новее. На деле это вещи разной природы: SOAP — протокол обмена сообщениями со строгими правилами и обширным набором стандартов вокруг, REST — архитектурный стиль, который описывает принципы, а не формат. Поэтому корректный вопрос не «что лучше», а «какие свойства нужны интеграции и что их даёт дешевле». Разберём, как устроены оба подхода, где каждый из них уместен сегодня, что действительно устарело и что используют вместо них.
SOAP: протокол со строгим конвертом
SOAP (изначально Simple Object Access Protocol) появился в конце 1990-х, версия 1.1 опубликована в 2000 году, 1.2 стала рекомендацией W3C в 2003-м. Каждое сообщение — XML-документ определённой структуры:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ord="http://example.com/orders">
<soap:Header>
<!-- служебные данные: подпись, адресация, идентификатор сообщения -->
</soap:Header>
<soap:Body>
<ord:GetOrderRequest>
<ord:orderId>7f3c2a10-0b1e-4c8e-9d55-2a4f1e6b9c01</ord:orderId>
</ord:GetOrderRequest>
</soap:Body>
</soap:Envelope>Ключевые элементы экосистемы:
- Envelope, Header, Body — конверт, заголовки для инфраструктуры (безопасность, маршрутизация, транзакции) и полезная нагрузка;
- Fault — стандартный формат ошибки внутри Body с кодом, описанием и детализацией;
- WSDL — описание сервиса: операции, входные и выходные сообщения, привязка к транспорту и адрес;
- XSD — схемы данных с богатой системой типов: ограничения длины и шаблона, перечисления, наследование и сложные типы;
- WS-* — семейство расширений: WS-Security (подпись и шифрование отдельных частей сообщения), WS-Addressing (адресация и асинхронные ответы), WS-ReliableMessaging (гарантированная доставка), WS-AtomicTransaction (распределённые транзакции), WS-Policy (требования сервиса);
- MTOM — передача больших бинарных вложений без раздувания XML кодировкой base64.
Важное свойство SOAP — независимость от транспорта. Чаще всего сообщения идут поверх HTTP POST, но тот же конверт можно передать через очередь сообщений (JMS, IBM MQ) или почту. HTTP здесь лишь «труба», семантика операции целиком внутри XML.
Стиль привязки тоже имеет значение. Исторически существовали варианты RPC/encoded, RPC/literal, document/literal. Сегодня де-факто стандарт — document/literal wrapped: тело содержит один элемент, названный по операции и описанный в XSD. Профиль WS-I Basic Profile ещё в 2004 году запретил encoded-стиль из-за проблем совместимости между платформами.
REST: архитектурный стиль
REST (Representational State Transfer) описал Рой Филдинг в диссертации 2000 года как набор ограничений, которым следует архитектура веба:
- клиент-сервер — разделение ответственности;
- отсутствие состояния сессии на сервере — каждый запрос самодостаточен;
- кэшируемость — ответы явно помечаются как кэшируемые или нет;
- единообразный интерфейс — ресурсы с идентификаторами (URI), манипуляция через представления, самоописывающие сообщения, гипермедиа как механизм перехода между состояниями (HATEOAS);
- многоуровневая система — между клиентом и сервером могут стоять прокси, шлюзы, кэши;
- код по запросу — необязательное ограничение.
На практике REST-ом называют HTTP API, которые моделируют предметную область как ресурсы и используют семантику HTTP: методы, коды ответов, заголовки кэширования и согласования содержимого.
GET /orders/7f3c2a10-0b1e-4c8e-9d55-2a4f1e6b9c01 HTTP/1.1
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
ETag: "v42"
{ "id": "7f3c2a10-...", "status": "PAID", "total": { "amount": 1500, "currency": "RUB" } }Модель зрелости Ричардсона хорошо показывает, насколько API действительно следует стилю:
- Уровень 0 — один адрес и один метод, внутри тела указывается, что сделать. По сути, RPC поверх HTTP; SOAP формально находится здесь.
- Уровень 1 — появляются ресурсы с отдельными адресами.
- Уровень 2 — используются методы HTTP по назначению (GET читает, POST создаёт, PUT заменяет, PATCH изменяет частично, DELETE удаляет) и коды ответов (201, 404, 409, 422 и т. д.).
- Уровень 3 — ответы содержат ссылки на возможные следующие действия (гипермедиа).
Подавляющее большинство «REST API» в индустрии — это уровень 2. Гипермедиа встречается редко: клиенты всё равно пишутся под конкретный API, а ссылки в ответах усложняют контракт. Это нормально: для интеграции важна предсказуемость, а не соответствие диссертации.
REST не задаёт формат данных, но в подавляющем большинстве случаев это JSON. Контракт описывают в OpenAPI, ошибки — в формате Problem Details (RFC 9457, ранее RFC 7807): единая структура с полями type, title, status, detail.
Сравнение по существу
| Аспект | SOAP | REST (JSON over HTTP) |
|---|---|---|
| Природа | протокол со строгой структурой сообщений | архитектурный стиль поверх HTTP |
| Формат данных | только XML | любой, обычно JSON |
| Контракт | WSDL + XSD, исторически обязателен | OpenAPI, формально необязателен |
| Типизация | строгая, богатая система типов XSD | JSON Schema; строгость зависит от дисциплины |
| Транспорт | HTTP, очереди, другие | HTTP |
| Ошибки | SOAP Fault, обычно с HTTP 500 | коды HTTP + тело Problem Details |
| Безопасность | TLS и WS-Security: подпись и шифрование на уровне сообщения | TLS, OAuth 2.0 / OpenID Connect, JWT; подпись сообщения — отдельными решениями (JWS, HTTP Message Signatures) |
| Надёжная доставка, транзакции | стандартизированы (WS-ReliableMessaging, WS-AtomicTransaction), но поддерживаются неравномерно | не стандартизированы; идемпотентность, повторы и саги проектируются явно |
| Кэширование | практически нет (всё через POST) | штатное кэширование HTTP: ETag, Cache-Control, CDN |
| Объём и скорость | XML-конверт, разбор тяжелее | компактнее, разбор быстрее |
| Порог входа | высокий без генераторов кода | низкий, запрос можно отправить из браузера или curl |
| Инструменты | зрелые в Java и .NET; SoapUI | повсеместные: любой язык, браузер, Postman, шлюзы API |
Несколько важных уточнений к таблице:
- Безопасность на уровне сообщения — главное реальное преимущество SOAP. TLS защищает канал между двумя точками, а WS-Security позволяет подписать конкретный документ, который пройдёт через несколько посредников и будет храниться как юридически значимый. Для REST аналогичные задачи решают подписью JWS или откреплённой подписью документа, но единого распространённого стандарта нет.
- «SOAP надёжнее» — утверждение неточное. Стандарты WS-ReliableMessaging и WS-AtomicTransaction существуют, но в реальных интеграциях встречаются редко. Надёжность в обоих мирах обычно обеспечивают одинаково: идентификатор сообщения, идемпотентная обработка, повторы и журнал.
- Строгость типов — не свойство REST или SOAP, а свойство контракта. OpenAPI с JSON Schema и генерацией кода даёт сопоставимую строгость. Разница в культуре: в SOAP-мире схема есть всегда, в REST-мире её приходится требовать.
Где используется SOAP сегодня
SOAP перестал быть выбором по умолчанию для новых публичных API примерно в начале 2010-х, но остаётся рабочим стандартом в отраслях, где важны формальная схема, подпись документов и долгий жизненный цикл интеграций:
- государственные информационные системы — межведомственный электронный обмен во многих странах построен на SOAP с подписью сообщений; в России это прежде всего СМЭВ и подключаемые к ней ведомственные сервисы, где XML-сообщения подписываются по ГОСТ;
- банки и платёжная инфраструктура — обмен с регуляторами, процессингом, бюро кредитных историй; плюс большой пласт внутренних интеграций с АБС;
- страхование, телеком, энергетика — биллинг, OSS/BSS, обмен с партнёрами по отраслевым схемам;
- корпоративные системы — ERP и CRM крупных вендоров, сервисные шины (ESB), интеграционные платформы;
- отраслевые стандарты на XML — авиаперевозки, логистика, медицина (HL7 v3) — схемы описаны в XSD, и SOAP-транспорт для них естественен.
Общее у этих областей: интеграции живут 10–20 лет, участников много и они независимы, документы имеют юридическую силу, а изменения согласуются формально. Перевести такую экосистему на REST — дорогой проект без явной выгоды для бизнеса, поэтому SOAP там будет жить долго. Системному аналитику в этих отраслях знание WSDL и XSD нужно не меньше, чем OpenAPI.
Где используется REST
- публичные API облачных сервисов, платёжных систем, маркетплейсов, мессенджеров;
- связка frontend и backend веб- и мобильных приложений;
- взаимодействие микросервисов там, где не выбран gRPC или обмен событиями;
- открытые банковские API (open banking) — стандарты в разных странах, включая российские, ориентированы на REST, JSON и OAuth 2.0;
- новые государственные сервисы всё чаще публикуют REST-интерфейсы рядом со старыми SOAP-сервисами.
Что устарело, а что нет
Действительно устарело:
- UDDI — глобальный реестр веб-сервисов, который так и не взлетел; публичные реестры закрыты ещё в 2006 году;
- RPC/encoded стиль SOAP — несовместим с WS-I и современными инструментами;
- SOAP как выбор по умолчанию для нового публичного API — сторонние разработчики ожидают HTTP и JSON;
- большая часть WS-* за пределами WS-Security и WS-Addressing — стандарты есть, реальных внедрений мало;
- XML-RPC — предшественник SOAP, встречается только в наследии.
Не устарело:
- SOAP с document/literal в регулируемых и межорганизационных интеграциях — живой, поддерживаемый, с новыми версиями схем;
- XSD как язык описания документов — используется не только в SOAP, но и в форматах обмена файлами и электронных документах;
- WS-Security и XML-подпись — там, где нужна подпись документа, а не канала.
И обратное наблюдение: «REST» в его строгом смысле — с гипермедиа и самоописывающими сообщениями — тоже не стал массовым. Индустрия выбрала прагматичный HTTP API с хорошим контрактом.
Кроме REST и SOAP
Выбор давно не бинарный. Для полноты картины:
- gRPC — бинарный протокол поверх HTTP/2 с контрактом на Protocol Buffers. Высокая производительность, потоковая передача, строгая генерация кода. Стандарт для внутренних высоконагруженных микросервисов; в браузере нужен прокси.
- GraphQL — клиент сам описывает, какие данные получить. Удобен для сложных интерфейсов, агрегирующих много источников; сложнее с кэшированием, лимитами и контролем нагрузки.
- Обмен событиями — Kafka, RabbitMQ и другие брокеры с контрактами на AsyncAPI и реестрами схем. Подходит, когда системы должны реагировать на изменения, а не опрашивать друг друга.
- JSON-RPC — лёгкий RPC на JSON; на нём, например, построен протокол MCP для подключения инструментов к ИИ-агентам.
- OData — стандартизированный REST-протокол для запросов к данным с фильтрацией и выборкой полей, распространён в продуктах SAP и Microsoft.
Как выбирать
- Если контрагент уже определил протокол — вопроса нет. Государственный сервис на SOAP подключается по SOAP, партнёр с REST API — по REST. Ваша задача — изолировать особенности внешнего протокола в адаптере, чтобы они не расползлись по системе.
- Нужна подпись документа с юридической значимостью и проход через посредников — SOAP с WS-Security или отраслевой XML-стандарт естественнее. В REST придётся проектировать подпись самостоятельно.
- Публичный API, веб, мобильные клиенты — REST с OpenAPI.
- Внутренние высоконагруженные вызовы — gRPC или REST, если команде важнее простота отладки.
- Реакция на изменения в других системах — события через брокер, а не опрос по REST или SOAP.
В крупных ландшафтах оба протокола сосуществуют. Типовое решение — шлюз или интеграционный слой, который принимает SOAP от внешних участников и публикует внутри REST или события, и наоборот. При таком подходе важно, чтобы преобразование было явно описано: WSDL и XSD на внешней стороне, OpenAPI или AsyncAPI на внутренней, и таблица соответствия полей между ними — тоже часть постановки.
Практические советы аналитику
- Для SOAP-интеграции начинайте с WSDL и XSD контрагента: проверьте их валидатором, найдите все обязательные элементы и ограничения, соберите пример сообщения и прогоните его через схему до того, как писать постановку.
- Фиксируйте в требованиях не только успешный сценарий, но и перечень Fault или кодов ошибок, поведение при таймауте и повторной отправке.
- Для REST требуйте контракт OpenAPI даже от внутренних команд — это та же строгость, которую SOAP даёт по умолчанию.
- Описывайте идемпотентность явно: какой ключ гарантирует, что повторный запрос не создаст второй платёж или заказ.
- При проектировании адаптера между протоколами составляйте таблицу соответствия полей с правилами преобразования типов, дат, перечислений и пустых значений: именно здесь чаще всего возникают ошибки.
REST и SOAP решают разные задачи и будут сосуществовать ещё долго. Умение работать с обоими — и понимать, какие свойства интеграции на самом деле нужны, — ценнее, чем приверженность одному из них.
Описания для обоих миров можно готовить в онлайн-редакторах WSDL, XSD и OpenAPI; синтаксис разобран в документации по WSDL и XSD.