SOAP и gRPC

SOAP и подпись на уровне сообщения

SOAP - протокол обмена, где каждое сообщение упаковано в XML-конверт со служебным заголовком и телом. Контракт описывается отдельным файлом на языке WSDL (web services description language): в нём перечислены доступные операции, структуры данных и адреса. По этому файлу инструменты генерируют готового клиента, руками его писать не надо.

Многословен и тяжёл - это чистая правда, XML-конверт легко весит вдвое больше полезных данных. Но у SOAP есть то, чего у REST нет из коробки: набор расширений WS-Security подписывает и шифрует само сообщение, а не канал, по которому оно едет.

Разница принципиальная. HTTPS защищает участок передачи: пока данные летят по проводу, их не прочитать и не подменить. Как только сообщение доехало, легло в шину, потом в базу, потом в архив - от HTTPS не осталось ничего. Подпись же едет вместе с документом: достав его из архива через год, можно доказать, что он не менялся и пришёл именно от этой стороны.

// Именно поэтому в финансах SOAP не выкинули. Спор о содержании платёжного поручения возникает не в момент передачи, а через месяцы, когда канала давно нет, а документ есть.

gRPC: внутрь, а не наружу

gRPC устроен из двух частей. Транспорт - HTTP/2, который умеет держать много параллельных запросов в одном соединении и передавать потоки в обе стороны. Формат данных - Protobuf: описываешь структуру сообщения в отдельном файле схемы, а по проводу едут компактные двоичные данные без имён полей, только значения по порядку.

Отсюда его сильные стороны: сообщений уходит в разы меньше по объёму, контракт строгий, клиенты генерируются по схеме. Внутри своего контура, где сервисы дёргают друг друга тысячи раз в секунду, это заметная экономия.

И отсюда же слабые. Партнёру наружу нужен файл схемы и специальный инструментарий, обычным curl такой вызов не отладишь, а в браузере он без прослойки не работает вовсе. Двоичный формат нельзя открыть глазами и посмотреть, что пришло.

// Поэтому для публичных интерфейсов REST с JSON остаётся практичнее просто из-за порога входа. Любой партнёр умеет отправить HTTP-запрос и прочитать JSON-ответ, и никакой подготовки для этого не требуется.

Кодогенерация и наследуемые системы

У генерации клиента по контракту есть неочевидное достоинство. Сгенерированный код повторяет структуру схемы, поэтому переименование поля или смена типа у партнёра ломают сборку, а не прод. Ошибка обнаруживается в момент обновления схемы, когда починка стоит десять минут, а не ночью в проде, когда она стоит инцидента.

Отдельная типовая задача аналитика - встроить в современный ландшафт систему, которая умеет только обмен файлами по расписанию. Переписать её обычно нельзя: она работает двадцать лет, исходников половина, а автор давно на пенсии.

Тащить файловый обмен во все окружающие сервисы тоже вредно - устаревший протокол расползётся и останется навсегда. Правильное решение - адаптер: отдельный компонент забирает файл, разбирает его и публикует события в общую шину, а в обратную сторону собирает файл из сообщений.

// Смысл адаптера в изоляции: старый протокол живёт ровно в одной точке системы, и когда наследуемую систему наконец заменят, переписывать придётся только адаптер, а не двадцать потребителей.

Как отвечать: «Банк требует SOAP с подписью. Чем это лучше REST по HTTPS?»

Тем, что подпись живёт в самом сообщении, а не в канале. HTTPS защищает участок передачи: как только сообщение дошло и легло в шину или в базу, от этой защиты не остаётся ничего. WS-Security подписывает содержимое, и подпись едет вместе с документом - через год его можно достать из архива и доказать, что он не менялся и пришёл именно от этой стороны. В финансовых интеграциях это принципиально, потому что спор о содержании платёжного поручения возникает не в момент передачи, а сильно позже, когда канала давно нет. Многословность XML-конверта тут осознанная плата, и она дешевле, чем невозможность доказать свою правоту.

Ответ разводит защиту канала и защиту документа, объясняет, почему это важно именно в финансах, и признаёт цену решения вместо того, чтобы защищать протокол целиком.

На чём валятся

• −− Говорят «SOAP устарел», не понимая роли подписи на уровне сообщения.
• −− Выносят gRPC наружу партнёрам и получают высокий порог входа и неотлаживаемый обмен.
• −− Считают HTTPS достаточным там, где нужна доказуемость документа во времени.
• −− Тащат в документ интеграции внутреннее устройство партнёра вместо контракта.
• −− Предлагают переписать наследуемую систему вместо того, чтобы изолировать её адаптером.