Чем отличается REST от SOAP?

REST vs SOAP

REST и SOAP — два парадигмально разных подхода к построению веб-сервисов. REST доминирует в современной разработке, но SOAP остаётся в enterprise систем. Как System Analyst нужно понимать различия для выбора архитектуры.

Основные определения

SOAP (Simple Object Access Protocol) — это протокол с строгой спецификацией, основанный на XML. Это набор правил для обмена структурированными данными.

REST (Representational State Transfer) — это архитектурный стиль, использующий HTTP как есть. REST опирается на HTTP методы и stateless взаимодействие.

Сравнение по аспектам

1. Протокол и транспорт

SOAP:

• Работает только по HTTP/HTTPS (хотя спецификация позволяет и другие протоколы)
• Использует HTTP как транспортный слой, не понимая его семантики
• Весь запрос упаковывается в XML конверт (SOAP Envelope)

REST:

• Полностью использует семантику HTTP: методы (GET, POST, PUT, DELETE), статус-коды, headers
• Может работать с другими протоколами, но HTTP — основной
• Любой стандартный HTTP клиент может работать с REST API

2. Формат данных

SOAP:

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetUser xmlns="http://example.com">
      <userId>123</userId>
    </GetUser>
  </soap:Body>
</soap:Envelope>

• Всегда XML
• Много overhead из-за теговости
• Строгая структура, заданная WSDL

REST:

GET /api/users/123
Accept: application/json

{
  "id": 123,
  "name": "John",
  "email": "john@example.com"
}

• Обычно JSON (легче, компактнее)
• Может быть XML, CSV, другой формат
• Гибкая структура

3. Определение контракта

SOAP:

• WSDL (Web Services Description Language) — XML файл, описывающий все операции
• Строгая типизация
• Контракт автоматически генерирует код клиента
• Сложность: WSDL файл часто больше, чем сам сервис

REST:

• OpenAPI (Swagger) — документация в JSON/YAML
• Более гибко и читаемо
• Инструменты генерируют клиентские библиотеки
• Проще документировать и изменять

4. Операции и методы

SOAP:

• Все операции — это методы в сервисе
• Не различает операции по метаболизму (GET/POST/PUT)
• Например: GetUser, CreateUser, UpdateUser — все через POST

<soap:Body>
  <CreateUser>
    <name>John</name>
  </CreateUser>
</soap:Body>

REST:

• Использует HTTP методы для семантики операции:
  • GET — получить ресурс
  • POST — создать ресурс
  • PUT/PATCH — обновить ресурс
  • DELETE — удалить ресурс
• Ресурс идентифицируется URL (/users/123)

5. Stateless vs State

SOAP:

• Может поддерживать состояние сеанса (WS-ReliableMessaging)
• Более сложное управление жизненным циклом

REST:

• Stateless по определению — каждый запрос независим
• Масштабируется горизонтально проще
• Если нужна сессия — в базе, не в сервисе

6. Производительность

SOAP:

• Большой overhead из-за XML
• Парсинг XML дороже JSON
• Пример: запрос в 50 байт + SOAP конверт ≈ 300+ байт

REST:

• Компактные JSON ответы
• Меньше трафика
• Может использовать HTTP caching (304 Not Modified)

7. Кэширование

SOAP:

• Сложно кэшировать (все запросы POST)
• Прокси не понимают SOAP операции
• Требует специальной кэширующей логики

REST:

• Встроенное кэширование через HTTP (GET, ETag, Cache-Control)
• CDN автоматически кэширует GET запросы
• Просто и эффективно

Таблица сравнения

Когда использовать что

SOAP:

• Требуется строгая типизация и контракт
• Нужна высокая безопасность (WS-Security, шифрование)
• Legacy системы и интеграция с banking/insurance
• Асинхронная обработка с гарантированной доставкой

REST:

• Public API и мобильные приложения
• Микросервисная архитектура
• Нужно кэширование и масштабируемость
• Быстрая разработка и итерация
• Современные приложения

Примеры из реальной практики

SOAP используется:

• Интеграция с банками (платёжные системы)
• Системы бронирования авиабилетов
• Enterprise middleware (Oracle, SAP)

REST используется:

• Twitter, GitHub, Google APIs
• Мобильные приложения
• Микросервисы (как в нашем случае)

Заключение

Для современного System Analyst REST — стандарт де-факто. Однако знание SOAP критично для:

• Интеграции с legacy системами
• Понимания архитектурных выборов
• Обсуждения с enterprise клиентами

Выбор между ними — это архитектурное решение, которое зависит от требований, а не от моды.