Корпоративные системы перестали жить поодиночке. Учётный контур, биллинг, складская программа, ведомственный реестр – каждый требует данных от соседа. Файловый обмен по расписанию и прямой доступ в чужую базу мы прошли: они ломаются при первом же изменении схемы и не оставляют следов для аудита. Веб-сервисы дают то, чего не хватало, – описанный контракт, транспорт поверх HTTP и независимость от платформы. Сегодня выбор сводится к двум подходам: тяжёлому SOAP и лёгкому REST. Разберём, где работает каждый.

SOAP: строгий контракт и тяжёлая обвязка

SOAP – это конверт XML поверх HTTP (реже SMTP) с описанием интерфейса в WSDL. Сильная сторона – формальность. WSDL задаёт операции, типы и структуры до строчки, а инструменты под .NET и Java генерируют по нему клиент и сервер автоматически. Для интеграции с банками, казначейством и ведомственными шлюзами это решает: контракт согласован заранее, обе стороны кодогенерируют заглушки, разночтений нет.

Вокруг SOAP выросло семейство стандартов WS-*. WS-Security подписывает и шифрует отдельные элементы сообщения, а не только канал, – критично, когда сообщение проходит через несколько посредников. WS-ReliableMessaging гарантирует доставку, WS-AtomicTransaction тянет распределённую транзакцию через несколько сервисов. В госсекторе и банковской интеграции, где требуют ЭЦП на уровне документа и сквозную транзакционность, альтернатив SOAP сейчас по сути нет.

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

REST: ресурсы, HTTP и минимум церемоний

REST не стандарт, а архитектурный стиль: оперируем ресурсами по URL, а методы HTTP – GET, POST, PUT, DELETE – задают действие. Никакого конверта, ответ отдаётся прямо в XML или JSON. Кэширование, коды состояния, заголовки – всё берётся из самого HTTP, который и так работает в любой инфраструктуре.

Выигрыш – в простоте и скорости разработки. REST-сервис отлаживается обычным браузером и curl, нагрузка на канал ниже, порог входа для внешних разработчиков минимальный. Поэтому открытые API публичных сервисов всё чаще делают именно в этом стиле. Для мобильных клиентов, где трафик и батарея на счету, лёгкость REST решает напрямую – мы писали об этом, разбирая корпоративный потенциал iPhone 3GS.

Минусы – обратная сторона свободы. Формального контракта уровня WSDL нет, описание держится на документации, которую легко рассинхронизировать с кодом. Шифрование на уровне отдельного поля, гарантированная доставка, распределённые транзакции из коробки не идут – придётся достраивать руками.

Как выбирать

Не противопоставляйте подходы догматически. Решает характер задачи.

  • Жёсткий контракт, ЭЦП на документе, распределённые транзакции, интеграция с госшлюзами и банками – SOAP.
  • Чтение данных, открытые API, мобильные и веб-клиенты, высокая частота вызовов – REST.

В реальном проекте они уживаются: внутренний контур на SOAP, внешний доступ – через REST-фасад. Главное – закрепить выбор и зону ответственности сторон в SLA на интеграционные работы, иначе сопровождение превратится в спор о том, чья сторона сломала обмен.

Вывод

SOAP и REST – инструменты для разных задач, а не конкуренты. SOAP берёт строгостью контракта и стеком WS-* там, где цена ошибки высока. REST выигрывает простотой и скоростью там, где нужен лёгкий доступ к данным. Грамотная интеграция начинается не с выбора технологии, а с разбора сценариев обмена и проектирования интеграции под конкретный ландшафт, где SOAP и REST расставлены по своим зонам ответственности.