REST vs SOAP vs gRPC vs GraphQL: гайд для системного аналитика

Зачем сравнение спрашивают

На собесе SA в банке/ритейле/телекоме часто звучит: «вам приходит требование интеграции с поставщиком — поставщик предлагает SOAP, ваш стек REST. Что описываете в ТЗ?» или «как обоснуете выбор gRPC между микросервисами вместо REST?». Это не теоретический вопрос — аналитик должен уметь обосновать выбор, понимать риски и описать в ТЗ.

Главная боль без понимания протоколов — кандидат на каждый вопрос отвечает «REST», даже когда контекст требует другого. На банковском собесе в финтехе это закрывает кандидату дверь, потому что банковские интеграции — это половина SOAP, треть REST, остальное gRPC/файловый обмен.

Эта статья даёт базовую матрицу выбора, без неё сложно проходить SA-собесы middle+.

REST

REST — архитектурный стиль над HTTP. Ресурсы (existeentities), URI — адреса ресурсов, методы (GET/POST/PUT/PATCH/DELETE) — действия.

GET /users/123
POST /orders
{
  "user_id": 123,
  "amount": 1000
}

Плюсы:

• Стандарт де-факто для публичных API
• Понятен любому разработчику
• Хорошо кешируется (GET через CDN)
• Документация через OpenAPI 3.x
• HTTP-инфраструктура (proxy, load balancer, gateway) работает без настройки

Минусы:

• Нет строгого контракта в самом стандарте (нужен OpenAPI отдельно)
• Multi-resource запросы — N+1 (загрузить пользователя и его заказы — два HTTP-запроса)
• Бинарные данные неудобны (base64 в JSON раздувает размер)
• Streaming — костылями (chunked, SSE)

Когда выбирать: публичные API, мобильные/веб-клиенты, partner-API, когда нужна простота и кеширование.

SOAP

SOAP — XML-based RPC протокол. Сообщения в SOAP envelope, контракт описывается WSDL.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetUserRequest>
      <userId>123</userId>
    </GetUserRequest>
  </soap:Body>
</soap:Envelope>

Плюсы:

• Жёсткий контракт через WSDL — клиент-серверная договорённость формальна
• WS-Security — встроенная безопасность сообщений (подпись, шифрование на уровне сообщения, не только канала)
• WS-ReliableMessaging — гарантии доставки на уровне протокола
• WS-AtomicTransaction — распределённые транзакции
• Стандарт в банках, госуслугах, страховых, enterprise-интеграциях

Минусы:

• Многословный (XML envelope + headers)
• Тяжёлый для мобильных/веб
• Сложнее в отладке
• Меньше инструментов для скетчинга/тестирования (есть SoapUI, Postman частично)

Когда выбирать: интеграция с банками, госуслугами (СМЭВ), страховыми, enterprise-системами, где WS-* стандарты обязательны или партнёр уже на SOAP.

В РФ SOAP ≠ legacy — это рабочий формат для большинства финтех/госовских интеграций.

gRPC

gRPC — Google RPC поверх HTTP/2 с Protocol Buffers (binary serialization).

service UserService {
  rpc GetUser (GetUserRequest) returns (User);
  rpc StreamOrders (StreamOrdersRequest) returns (stream Order);
}

message GetUserRequest {
  int64 user_id = 1;
}

Плюсы:

• Бинарный протокол → компактный, быстрый
• Strongly-typed контракт через proto-файлы
• Codegen для 10+ языков (Go, Java, Python, C#, Node, ...)
• HTTP/2 — мультиплексирование, server push, low-latency
• Streaming в обе стороны (клиент → сервер, сервер → клиент, bidirectional)
• Легко делать deadline/timeout, retry, load balancing на уровне клиента

Минусы:

• Не для браузера напрямую (нужен gRPC-Web прокси)
• Не кешируется через стандартные HTTP-CDN
• Сложнее отлаживать (бинарь, не текст)
• HTTP/2 нужно сквозь все прокси (старые балансировщики могут не уметь)

Когда выбирать: микросервис ↔ микросервис, low-latency RPC, потоки данных в реальном времени, polyglot-стеки. Не для публичного API мобилке/фронту.

GraphQL

GraphQL — query language для API. Один endpoint /graphql, клиент сам описывает, какие поля и какие связанные сущности нужны.

query {
  user(id: 123) {
    name
    email
    orders(last: 10) {
      id
      amount
      items {
        name
        price
      }
    }
  }
}

Плюсы:

• Клиент берёт ровно нужные поля → меньше over-fetching и under-fetching
• Один запрос вместо N+1
• Сильная типизация через SDL (Schema Definition Language)
• Удобно для фронта, особенно сложных интерфейсов с разнородными данными

Минусы:

• Сложнее кешировать (POST на один URL)
• Сложнее rate limiting и cost analysis (один запрос может загрузить весь датасет)
• Сложнее авторизация (на уровне поля, не URL)
• Серверу сложнее: N+1 на бэкенде, нужны DataLoaders/batch
• Не подходит для серверных интеграций («дай мне отчёт по контракту» удобнее на REST)

Когда выбирать: клиентский API мобильного/веб-приложения с множественными view, агрегатор API из нескольких бэкендов (BFF). Не выбирать для server-to-server интеграций между микросервисами.

Матрица выбора

Сценарий → выбор:

Правило для ТЗ: если партнёр уже определился — это решено, описываем под него. Если выбираем мы — обосновываем матрицей выше с явным trade-off.

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

REST на всё. «Микросервисы общаются по REST, потому что REST» — без оценки latency и нагрузки. На горячем пути 1000 RPS REST-JSON может стоить в разы дороже gRPC.

GraphQL для серверных интеграций. Микросервис A зовёт B через GraphQL — оверкилл. Контракт и так известен, гибкие запросы не нужны, добавляется сложность.

SOAP «в современном стеке не место». В банке/госе SOAP — стандарт. Аналитик, который не умеет описывать SOAP-интеграцию, не пройдёт собес в финтех.

gRPC между фронтом и бэкендом без gRPC-Web. Браузер не умеет нативный gRPC. Нужен прокси Envoy/Nginx с gRPC-Web.

Игнорировать кеширование. REST GET кешируется через CDN бесплатно — это огромный плюс на статичных endpoints. GraphQL/POST такой возможности из коробки не даёт.

Не описывать в ТЗ retry и таймауты. Любой протокол, если не описать поведение при сетевых сбоях, превратится в продакшен-инцидент.

Выбор «из тренда». GraphQL стал популярным → выбираем GraphQL для всего. Через год команда переписывает половину API обратно на REST.

Связанные темы

• REST API на собесе SA
• HTTP методы и коды на собесе SA
• JWT на собесе SA
• Подготовка к собесу системного аналитика
• Что такое API: гайд для аналитика

FAQ

REST это протокол или архитектурный стиль?

Архитектурный стиль (Roy Fielding, 2000). Протокол — HTTP. Когда говорят «REST API» — имеют в виду HTTP-API, следующий REST-принципам (ресурсы, методы, stateless, cacheable).

Чем gRPC лучше REST на цифрах?

Бинарный protobuf на 30–60% компактнее JSON. HTTP/2 мультиплексирование избавляет от head-of-line blocking. На low-latency RPC между микросервисами разница в latency — 2–5× в пользу gRPC.

GraphQL заменяет REST?

Нет. GraphQL хорош для клиентских API с разнородными view. REST — для серверных интеграций, публичных партнёрских API, простых CRUD. На крупных продуктах часто сосуществуют: GraphQL BFF поверх REST-микросервисов.

SOAP в новых проектах писать?

Если требование партнёра/регулятора — да. Если выбор за нами — нет, REST/gRPC проще. Но переписать legacy SOAP на REST «потому что устарело» — обычно не стоит, риск/выгода плохие.

Что писать в ТЗ для выбора протокола?

Контекст (кто потребитель), тип нагрузки (запрос-ответ vs streaming vs батч), требования по latency, требования по безопасности (WS-Security?), кешируемость, ограничения партнёра. Затем — обоснование выбора.

Это официальная информация?

Нет. Статья основана на спецификациях REST/HTTP (RFC 9110), SOAP (W3C), gRPC (proto3), GraphQL (graphql-spec) и общей практике. Конкретные требования к интеграции зависят от партнёра и компании.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.