SOAP vs REST

Введение: Два мира API

Представьте, что вам нужно отправить важный документ. У вас есть два варианта: отправить заказное письмо с уведомлением, описью вложения, заказом и страховкой — или отправить обычное письмо. Заказное письмо дойдёт точно, за него можно отследить, оно защищено, но оно дороже и сложнее. Обычное письмо быстрее и проще, но нет гарантий.

SOAP — это “заказное письмо”. Формальное, надёжное, безопасное, но тяжёлое. REST — это “обычное письмо”. Простое, быстрое, гибкое, но с меньшими гарантиями.

SOAP (Simple Object Access Protocol) — протокол, строгий, формальный, многословный. Предоставляет встроенные механизмы безопасности, транзакций, надёжности.

REST (Representational State Transfer) — архитектурный стиль, гибкий, простой, лёгкий. Использует HTTP методы и статусы естественным образом.

Выбор между SOAP и REST — это не вопрос “что лучше”. Это вопрос “что подходит для моей задачи”. В этой теме мы детально сравним два подхода, чтобы вы могли принимать осознанные решения.

Основные различия

Формат сообщений

SOAP: Только XML

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:user="http://example.com/user">
    <soap:Header>
        <user:Auth>
            <user:ApiKey>abc123</user:ApiKey>
        </user:Auth>
    </soap:Header>
    <soap:Body>
        <user:GetUserRequest>
            <user:UserId>123</user:UserId>
        </user:GetUserRequest>
    </soap:Body>
</soap:Envelope>

Размер: ~400 байт

REST: JSON (обычно)

GET /users/123
Authorization: Bearer token123

Размер: ~50 байт

или с телом:

{
    "user_id": 123
}

Вывод: REST значительно компактнее. Меньше трафика, быстрее обработка.

Транспорт

SOAP: Несколько транспортов

REST: Практически только HTTP

GET /users/123
POST /users
PUT /users/123
DELETE /users/123

Вывод: SOAP гибче по транспорту. REST проще — почти всегда HTTP.

Контракт (WSDL vs OpenAPI)

SOAP: Обязательный WSDL

WSDL (Web Services Description Language) — формальный XML контракт. Клиент не может вызвать SOAP сервис без WSDL (или без его предварительного изучения).

<portType name="UserPort">
    <operation name="GetUser">
        <input message="tns:GetUserRequest"/>
        <output message="tns:GetUserResponse"/>
    </operation>
</portType>

Что даёт:

• Строгий контракт
• Автоматическая генерация клиентского кода
• Проверка совместимости на этапе разработки

REST: Опциональный OpenAPI

OpenAPI (Swagger) — опциональная документация, не обязательная для работы.

paths:
  /users/{id}:
    get:
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: integer

Что даёт:

• Документацию
• Генерацию клиентов (опционально)
• Не влияет на работу API

Вывод: SOAP требует формального контракта. REST — нет. Это и плюс, и минус для каждого.

Состояние (Stateful vs Stateless)

SOAP: Может быть Stateful

SOAP сервер может запоминать состояние между вызовами.

<!-- Установка сессии -->
<soap:Header>
    <myapp:SessionId>session-123</myapp:SessionId>
</soap:Header>

Когда нужно: Многошаговые операции, корзина покупок, длительные транзакции.

REST: Stateless

Каждый REST запрос самодостаточен. Сервер не хранит контекст.

# Каждый запрос содержит аутентификацию
GET /users/123
Authorization: Bearer token123

GET /users/123/orders
Authorization: Bearer token123

Когда хорошо: Масштабирование (любой сервер обработает любой запрос), простота, кеширование.

Вывод: SOAP гибче (может быть stateful). REST проще и масштабируемее (stateless).

Безопасность

SOAP: WS-Security (встроенная)

Безопасность на уровне сообщения, не только транспорта.

<wsse:Security>
    <ds:Signature>...</ds:Signature>
    <xenc:EncryptedData>...</xenc:EncryptedData>
    <wsse:UsernameToken>...</wsse:UsernameToken>
</wsse:Security>

REST: HTTPS + OAuth/JWT

Безопасность на транспортном уровне (TLS). Аутентификация и авторизация — поверх.

# HTTPS шифрует канал
# JWT токен в заголовке
GET /users/123
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Вывод: SOAP даёт более тонкую безопасность (подпись, шифрование на уровне сообщения). REST проще, но для большинства сценариев HTTPS + JWT достаточно.

Транзакции

SOAP: WS-AtomicTransaction

Распределённые транзакции с ACID гарантиями (двухфазная фиксация).

<soap:Header>
    <wsat:AtomicTransaction>
        <wsat:TransactionID>tx-123</wsat:TransactionID>
    </wsat:AtomicTransaction>
</soap:Header>

Когда нужно: Банковские переводы, бронирование билетов (деньги не могут пропасть).

REST: Нет встроенных транзакций

Распределённые транзакции нужно реализовывать поверх:

# Идемпотентный ключ для защиты от дубликатов
POST /payments
Idempotency-Key: uuid-123-456
{"amount": 100}

Вывод: SOAP даёт ACID транзакции “из коробки”. REST требует дополнительных механизмов (Saga, идемпотентность).

Надёжность (Reliable Messaging)

SOAP: WS-ReliableMessaging

Гарантированная доставка, упорядочивание, устранение дубликатов.

<wsrm:Sequence>
    <wsrm:Identifier>seq-123</wsrm:Identifier>
    <wsrm:MessageNumber>1</wsrm:MessageNumber>
</wsrm:Sequence>

REST: Нет встроенной надёжности

Клиент сам должен реализовывать:

• Повторные попытки (retry)
• Идемпотентность
• Проверку порядка сообщений

# Пример повторной попытки
for i in range(3):
    try:
        response = requests.get(url)
        if response.status_code == 200:
            break
    except:
        time.sleep(2 ** i)

Вывод: SOAP даёт гарантии доставки “из коробки”. REST требует самодельных решений.

Кеширование

SOAP: Плохое

SOAP запросы почти всегда POST, которые не кешируются браузером, прокси, CDN.

POST /UserService HTTP/1.1
Content-Type: text/xml

<soap:Envelope>...</soap:Envelope>

REST: Хорошее

GET запросы кешируются стандартными механизмами HTTP.

GET /users/123
Cache-Control: max-age=300
ETag: "abc123"

# При повторном запросе
GET /users/123
If-None-Match: "abc123"
→ 304 Not Modified (без тела)

Вывод: REST значительно лучше для кеширования.

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

SOAP: Медленнее

• XML тяжелее парсить, чем JSON
• SOAP сообщения в 10-20 раз больше JSON
• WSDL валидация добавляет накладные расходы

REST: Быстрее

• JSON легче парсить
• Меньше данных по сети
• HTTP кеширование

Сравнение (условное):

Вывод: REST производительнее для большинства сценариев.

Читаемость и отладка

SOAP: Сложно

# Вызов SOAP через curl (сложно)
curl -X POST https://api.example.com/UserService \
  -H "Content-Type: text/xml" \
  -H "SOAPAction: GetUser" \
  -d '<?xml version="1.0"?><soap:Envelope ...>...</soap:Envelope>'

Инструменты: SoapUI, специальные генераторы.

REST: Просто

# Вызов REST через curl (просто)
curl https://api.example.com/users/123

Инструменты: curl, браузер, Postman.

Вывод: REST значительно удобнее для разработчиков.

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

Примеры реальных SOAP сервисов:

• Платёжные шлюзы (PayPal, Stripe — есть и REST, и SOAP)
• Банковские API (Sberbank, ВТБ — часто SOAP)
• Системы бронирования (авиабилеты, отели)
• Salesforce API (поддерживает и SOAP, и REST)

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

Примеры реальных REST API:

• Google APIs (Maps, Drive, Gmail)
• Twitter API
• GitHub API
• Stripe API
• Amazon Web Services (большинство)

Критерии выбора

Выбирайте SOAP, если:

Выбирайте REST, если:

Сравнительная таблица

Распространённые заблуждения

Заблуждение 1: “SOAP устарел”

SOAP активно используется в банках, страховых, государственных системах. Он не устарел, он специализирован.

Заблуждение 2: “REST небезопасен”

REST с HTTPS и JWT безопасен для большинства сценариев. Просто безопасность реализована на транспортном уровне, а не на уровне сообщений.

Заблуждение 3: “SOAP везде, где XML”

SOAP — это не просто XML. Это XML в строгом конверте с заголовками, пространствами имён, WSDL и расширениями.

Заблуждение 4: “REST всегда JSON”

REST может использовать XML, HTML, текст, бинарные данные. JSON просто самый популярный.

Заблуждение 5: “Можно использовать оба”

Можно. Многие сервисы (например, Salesforce, PayPal) поддерживают и SOAP, и REST. Но это усложняет поддержку.

Резюме для системного аналитика

1. SOAP и REST решают разные задачи. SOAP — для сложных корпоративных интеграций (безопасность, транзакции, надёжность). REST — для простых, быстрых, масштабируемых API.

2. SOAP — протокол. Строгие правила, формальный контракт (WSDL), много стандартов (WS-*). REST — архитектурный стиль. Принципы, гибкость, лёгкость.

3. Формат: SOAP — XML (тяжёлый). REST — JSON (лёгкий). Это влияет на производительность и читаемость.

4. Транзакции и надёжность: SOAP даёт “из коробки” (WS-AtomicTransaction, WS-ReliableMessaging). REST требует дополнительных механизмов (Saga, идемпотентность).

5. Безопасность: SOAP — WS-Security (подпись, шифрование на уровне сообщения). REST — HTTPS + JWT (безопасность на транспортном уровне).

6. Кеширование: REST значительно лучше (GET запросы кешируются). SOAP почти всегда POST.

7. Простота и популярность: REST выигрывает. Легче разрабатывать, тестировать, отлаживать. Больше инструментов, сообществ, примеров.