gRPC, SOAP, GraphQL и вебхуки

REST не единственный способ интеграции. В банках живёт SOAP, между микросервисами всё чаще gRPC, на фронте встречается GraphQL, внешние сервисы уведомляют через вебхуки. Аналитик должен понимать, что выбрать и что из этого следует.

SOAP

• Протокол обмена XML-сообщениями. Сообщение: Envelope → необязательный Header → Body, ошибка в элементе Fault.
• Контракт в WSDL: операции, сообщения, типы (XSD), адрес сервиса.
• Транспорт чаще HTTP (обычно POST), но возможен и другой.
• Стандарты WS-* дают подписи и шифрование на уровне сообщения (WS-Security), надёжную доставку.
• Где встречается: банки, госсистемы (СМЭВ исторически на SOAP), ERP, старые корпоративные шины.
• Минусы: многословный XML, тяжёлые библиотеки, сложнее отлаживать.

gRPC

• RPC-фреймворк поверх HTTP/2, сообщения в Protocol Buffers (бинарный формат, контракт в .proto).
• Код клиента и сервера генерируется из .proto для многих языков.
• Четыре вида вызовов: унарный, серверный поток, клиентский поток, двунаправленный поток.
• Быстрый и компактный, строгая схема, дедлайны и отмена из коробки.
• Минусы: браузер напрямую не умеет (нужен gRPC-Web или прокси), бинарный трафик сложнее читать, нужен общий доступ к .proto.

syntax = "proto3";
service OrderService {
  rpc GetOrder (GetOrderRequest) returns (Order);
}
message GetOrderRequest { string id = 1; }
message Order {
  string id = 1;
  string status = 2;
  int64 amount_kopecks = 3;
}

Номера полей это часть контракта: их нельзя менять и повторно использовать после удаления поля (помечают reserved). Добавлять новые поля можно, старые клиенты их проигнорируют.

GraphQL

• Один эндпоинт, клиент сам описывает, какие поля нужны. Убирает over-fetching и under-fetching.
• Схема строго типизирована, есть подписки (subscriptions).
• Сложности: кеширование HTTP-уровня, защита от тяжёлых запросов (ограничение глубины и сложности), проблема N+1 на сервере.
• Удобен как BFF для фронта с множеством экранов.

Вебхуки

Сервис сам вызывает ваш URL при событии (платёж прошёл, посылка доставлена). Что продумать:

• проверка подлинности (подпись HMAC, секрет, список IP);
• идемпотентная обработка: провайдер может прислать событие повторно;
• быстрый ответ 200 и обработка в фоне;
• что делать, если вебхук потерялся: сверка через API по расписанию.

Как выбрать

Ситуация	Выбор
Публичный API для партнёров	REST + OpenAPI
Внутренние вызовы между сервисами с высокой нагрузкой	gRPC
Интеграция с банком или госсистемой с готовым WSDL	SOAP
Фронт с множеством экранов и разными наборами полей	GraphQL
Внешний сервис уведомляет о событии	вебхук
Событие нужно многим потребителям, отправитель не ждёт ответа	брокер сообщений

Частые ошибки

• Выбирать протокол по моде, а не по потребителям и требованиям.
• Забывать про таймауты и ретраи в синхронных вызовах.
• Менять номера полей в protobuf.
• Принимать вебхук без проверки подписи.

Что спросят на собесе

• Чем SOAP отличается от REST?
• Что такое WSDL и protobuf?
• Почему gRPC быстрее REST с JSON?
• Когда выберешь GraphQL?
• Как надёжно принимать вебхуки от платёжного провайдера?