SOAP: что это, как работает WSDL и чем отличается от REST

SOAP — это протокол, по которому две системы обмениваются XML-сообщениями по заранее описанным правилам. Обычно сервис публикует WSDL, а клиент должен собрать запрос точно по контракту. Если формат нарушен, сервис часто вернёт Fault с формальной ошибкой.

SOAP чаще нужен там, где живут старые корпоративные интеграции: банки, страхование, ERP, 1С, госпорталы и партнёрский обмен. В таких контурах важны совместимость, формальный контракт, сертификаты и возможность доказать, какое сообщение реально ушло в систему. И формат там меняют редко.

SOAP строится вокруг XML-сообщения и строгого контракта. REST обычно строится вокруг ресурсов и HTTP-методов. Из-за этого SOAP тяжелее на старте, но удобнее там, где схема, ошибки и правила обмена должны быть описаны очень жёстко. Это важно для старых интеграций.

WSDL — это описание SOAP-сервиса. В нём указаны операции, сообщения, типы данных, адрес сервиса и другие правила вызова. По сути это договор между сторонами: без него трудно понять, какой XML отправлять и какую ошибку считать нарушением контракта.

Сначала смотрят на WSDL, фактический XML и ответ сервиса. Потом проверяют namespace, обязательные поля, сертификат, авторизацию, HTTP-слой и журналы обеих сторон. Важно понять, это транспортный сбой или Fault внутри самого SOAP-ответа и где потерялся контракт.

Базовый запрос собрать не так трудно. Сложность начинается позже: нужно понимать WSDL, XML-схему, namespaces, Fault, сертификаты и разницу между ошибкой контракта и сетевой проблемой. Поэтому SOAP лучше учить не по терминам, а на одном живом сервисе.

Envelope — корневой элемент любого SOAP-сообщения, «конверт», в который упакованы запрос или ответ. Внутри два блока: необязательный Header со служебной информацией (токены авторизации, идентификаторы транзакций, маршрутизация) и обязательный Body с полезной нагрузкой — параметрами вызываемой операции или ответом сервиса. Если что-то пошло не так, вместо обычного ответа в Body приходит элемент Fault с кодом и описанием ошибки. Сообщение без Envelope и Body сервер отклонит — стандарт здесь строгий.

Версия 1.2 получила статус рекомендации W3C, более строгую модель обработки ошибок и собственный media type application/soap+xml вместо text/xml. В 1.1 операция передаётся через HTTP-заголовок SOAPAction, в 1.2 — через параметр action в Content-Type. Также в 1.2 переработана структура Fault: вместо faultcode и faultstring — элементы Code и Reason. На практике корпоративные системы в банках и госсекторе до сих пор чаще работают на 1.1, поэтому аналитику полезно уверенно читать обе версии.

Идите от конца к началу: секция service показывает адрес (endpoint), binding — протокол и стиль вызова, portType — список операций с их входами и выходами, message — состав каждого запроса и ответа, types — структуры данных в формате XSD. Практический маршрут: найдите нужную operation в portType, посмотрите её input и output, затем спуститесь в types и разберите поля, типы и обязательность. Через 3–4 разобранных WSDL этот путь занимает минуты.

XSD (XML Schema Definition) описывает структуру данных: какие поля есть у запроса, их типы, обязательность, ограничения на длину и формат. Сервер валидирует входящее сообщение по схеме до выполнения логики — некорректный запрос отбивается сразу с понятной ошибкой. Для аналитика XSD — источник истины при постановке ТЗ на интеграцию: из схемы видно, что именно передавать, а споры «какое поле обязательное» решаются ссылкой на схему, а не перепиской.

SoapUI — настольный инструмент для работы с SOAP-сервисами: подгружаете WSDL, и он сам генерирует заготовки запросов по всем операциям. Дальше подставляете тестовые данные, отправляете запрос и смотрите ответ — без единой строки кода. Аналитики используют SoapUI, чтобы проверить сервис до передачи разработчикам, воспроизвести ошибку из продакшена или показать смежной команде рабочий пример вызова. В вакансиях системных аналитиков он встречается почти так же часто, как сам SOAP.

Да. Postman отправляет SOAP-запрос как обычный HTTP POST: в Body выбираете raw и XML, вставляете конверт с Envelope и Body, добавляете заголовок Content-Type: text/xml и при необходимости SOAPAction. Автогенерации запросов из WSDL, как в SoapUI, здесь нет — конверт собираете руками или копируете из документации. Postman удобен, когда команда уже живёт в нём и держит SOAP- и REST-запросы в одной коллекции.

SOAP не привязан к транспорту: конверт можно доставить любым протоколом. Чаще всего это HTTP/HTTPS — синхронный вызов «запрос — ответ», знакомый по обычным веб-сервисам. Вариант поверх JMS (Java Message Service) — асинхронный: сообщение кладётся в очередь, получатель забирает его, когда готов, а доставка гарантируется брокером. JMS-вариант встречается в банковских шинах данных (ESB), где потеря сообщения о платеже недопустима, а системы-участники работают в разном темпе.

WS-Security — стандарт безопасности на уровне самого сообщения, а не транспортного канала. В SOAP Header добавляются токены аутентификации (UsernameToken, SAML, X.509-сертификаты), цифровая подпись и шифрование отдельных частей конверта. Отличие от HTTPS принципиальное: HTTPS защищает канал между двумя точками, а WS-Security — само сообщение, даже если оно проходит через цепочку посредников. Поэтому стандарт закрепился в банках и госсистемах, где сообщение проверяют на каждом узле маршрута.

Идемпотентность — свойство операции давать один результат при повторном вызове с теми же данными. В SOAP нет HTTP-семантики методов, как в REST, поэтому идемпотентность закладывают в дизайн сервиса: в запрос добавляют уникальный идентификатор операции (requestId), а сервер хранит обработанные идентификаторы и на повтор возвращает прежний ответ вместо повторного списания или создания дубля. Аналитику при описании интеграции нужно явно фиксировать, какие операции безопасно повторять — от этого зависит логика ретраев.

Fault — стандартный формат ошибки: элемент в Body с кодом (faultcode), человекочитаемым описанием (faultstring) и опциональным блоком detail с подробностями от конкретного сервиса. Код Client означает проблему в запросе — неверная структура, непройденная валидация по XSD, отсутствие обязательного поля. Код Server — сбой на стороне сервиса. При разборе инцидента аналитик первым делом смотрит faultcode: он сразу делит зону ответственности между вызывающей и принимающей системами.

Платформа 1С:Предприятие умеет и публиковать собственные веб-сервисы по SOAP, и вызывать внешние. Конфигурация описывает операции, платформа сама генерирует WSDL — внешние системы подключаются к 1С как к обычному SOAP-сервису. Типовые сценарии: обмен документами между 1С и корпоративными системами, выгрузка данных в банк-клиент, интеграция с госсервисами. Отсюда заметный спрос на разработчиков 1С в SOAP-вакансиях — одна из самых частых ролей после системных аналитиков и QA.

Три причины. Первая — работающее наследие: интеграционные шины и АБС строились в 2000–2010-х на SOAP, переписывать их дорого и рискованно. Вторая — строгий контракт: WSDL и XSD жёстко фиксируют формат обмена, что снижает цену ошибки там, где сообщение — это платёж или юридически значимый документ. Третья — зрелые стандарты безопасности и надёжности: WS-Security, подпись сообщений, гарантированная доставка. Пока эти системы живут, спрос на специалистов со знанием SOAP никуда не денется.

Базовый цикл: загрузить WSDL в SoapUI, прогнать позитивные сценарии по каждой операции, затем негативные — пустые обязательные поля, неверные типы, нарушение XSD, некорректный токен в Header. Отдельно проверяют обработку Fault: сервис должен возвращать осмысленные коды, а не пустой ответ. В регресс добавляют проверку обратной совместимости контракта — не сломало ли обновление WSDL существующих потребителей. В московском IT-срезе тестирование даёт 18,7% SOAP-вакансий, и QA Manual — вторая роль по спросу.

Читать WSDL и XSD без подсказок разработчика: находить операции, разбирать структуры запросов и ответов, определять обязательность полей. Собирать и отправлять тестовые запросы в SoapUI или Postman. Описывать интеграции в спецификациях: маппинг полей между системами, обработка ошибок, сценарии повторов. Плюс контекст: как устроены интеграционные шины, чем SOAP отличается от REST и когда что уместно. Именно этот набор проверяют на собеседованиях — судя по 680 упоминаниям роли в московском IT-срезе, проверяют часто.

Редко «большим взрывом» — обычно через фасад: перед SOAP-сервисом ставят REST-прослойку (API gateway или адаптер), новые потребители ходят через REST, старые продолжают работать по SOAP. Аналитик здесь ключевая фигура: он составляет маппинг операций SOAP на ресурсы и методы REST, переносит правила валидации из XSD в JSON Schema или OpenAPI, описывает соответствие Fault-кодов HTTP-статусам. Полный вывод SOAP из эксплуатации в банках растягивается на годы — поэтому знание обоих подходов ценится выше, чем любого по отдельности.

Два порядка разработки сервиса. Contract-first: сначала пишут контракт — WSDL и XSD, — согласуют его со всеми участниками интеграции, потом генерируют код по контракту. Code-first: сначала пишут код сервиса, а WSDL генерируется из него автоматически. Enterprise-практика тяготеет к contract-first: контракт можно согласовать между банком и подрядчиком до начала разработки, и обе стороны пишут код параллельно. Для аналитика contract-first означает, что WSDL — его рабочий документ, а не побочный продукт кода.

Зарплату определяют роль и уровень, а не сам SOAP — актуальные данные смотрите в рыночном блоке этой страницы. Выборка смещена в сторону опытных специалистов: junior-вакансий мало, а перекос к senior — один из самых заметных среди интеграционных навыков. Логика простая: SOAP нужен там, где сложные enterprise-интеграции в банках, страховании и госсекторе, и туда ищут людей, способных самостоятельно разобрать чужой WSDL и спроектировать обмен. Порог входа выше — и оплата соответствующая.

Как навык для работы в enterprise — да. В московском IT-срезе SOAP стабильно упоминается в вакансиях, и спрос растёт. Новые публичные API на SOAP почти не строят, но банки, страховые, госсистемы и 1С-ландшафты продолжают жить на нём, и этим системам нужны аналитики, тестировщики и разработчики. Реалистичная стратегия: учить SOAP не вместо REST, а вместе с ним — REST встречается почти во всех тех же вакансиях, работодателю нужны оба.

Оба подхода контрактные: у SOAP контракт — WSDL и XML, у gRPC — proto-файл и бинарный Protocol Buffers поверх HTTP/2. gRPC быстрее и компактнее, поэтому его выбирают для взаимодействия микросервисов внутри компании. Но SOAP он не вытесняет: gRPC приходит в новые высоконагруженные системы, а SOAP остаётся в legacy-интеграциях банков и госсектора, где переписывание не окупается. Это разные ниши — в вакансиях системных аналитиков SOAP и gRPC почти не конкурируют между собой.