REST vs SOAP. Главное

Определение

SOAP (Simple Object Access Protocol) – протокол, который работает на XML и имеет стандарт.
REST – это архитектурный стиль, а не протокол. REST лишь определяет набор принципов и ограничений.

Протокол

SOAP активно использует разные транспортные протоколы помимо HTTP, например, SMTP и FTP. Но в большинстве случаев SOAP использует HTTP в качестве транспорта (SOAP over HTTP).
REST, как правило, хотя и не обязательно, использует HTTP. С одной стороны, REST не говорит, что нужно обязательно использовать HTTP. С другой стороны, HTTP специально спроектирован под REST. Более того, создатель REST Рэй Филдинг также является соавтором HTTP.

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

SOAP работает только с XML.
В REST нет ограничений по формату сообщений. REST API могут поддерживать любой формат сообщений, например XML, JSON, RSS, CSV, HTML и другие.

Подход к API

SOAP основан на подходе удалённого вызова процедур (RPC). Это вызов функции в коде, только по сети. Например, чтобы получить информацию о заказе, нужно вызвать SOAP-метод getOrder, чтобы оформить заказ – makeOrder и т.д.
REST фокусируется на ресурсах, доступ к которым осуществляется через URL. Это значит, например, что наш интернет-заказ имеет URI — /api/v1/order. Если мы хотим получить информацию о заказе, нужно вызвать HTTP метод GET /api/v1/order, чтобы оформить заказ, вызовем POST /api/v1/order. В обоих случаях ресурс один и тот же, а методы работы с ним разные.

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

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

Гибкость

SOAP сложнее масштабировать и вносить изменения. Сервер приложений также должен сохранять состояние каждого клиента. Это означает, что при обработке нового запроса он должен помнить все предыдущие, что усложняет масштабирование.
REST проще масштабировать, так как сервер не сохраняет состояние клиента, поэтому REST API обрабатывает каждый новый запрос независимо от предыдущих.

Простота

SOAP сложнее, требует глубокого понимания всех задействованных протоколов и их строгих правил. Реализация SOAP API требует описания WSDL для каждого сервиса, обрабатывать и анализировать XML сложнее.
REST проще в реализации и более “человекопонятен”. Он не привязан к XML и чаще всего использует JSON.

Обработка ошибок

В протокол SOAP встроена логика обработки ошибок. SOAP API позволяет возвращать XML-сообщение Retry с кодом ошибки и её объяснением.
REST использует протокол HTTP, который может возвращать коды состояний.

Раскрытие API

SOAP-сервис всегда должен иметь WSDL. Плюс этого в том, что WSDL даёт чёткие правила, как отправлять и по какой структуре отправлять запросы и принимать ответы.
REST не имеет языка описания веб-сервисов. Однако на помощь приходит Swagger (OpenAPI).

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

SOAP имеет встроенное расширение безопасности – WS Security, которое регулирует процедуры конфиденциальности и аутентификации для обмена сообщениями.
REST не предусматривает никаких специальных мер безопасности. Безопасность REST может быть обеспечена только за счет HTTPS.

Использование

SOAP применяется в системах, где нужна жёсткая стандартизация, а также в legacy.
REST используется повсеместно.

📌 Выводы

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

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

Критерий	REST	SOAP
Определение	Архитектурный стиль, определяющий набор принципов и ограничений	Протокол, работающий на XML и имеющий стандарт
Протокол	Как правило, использует HTTP, но не обязательно	Активно использует разные транспортные протоколы помимо HTTP
Формат сообщений	Поддерживает любой формат сообщений, например XML, JSON, RSS, CSV, HTML	Работает только с XML
Подход к API	Фокусируется на ресурсах, доступ к которым осуществляется через URL	Основан на подходе удалённого вызова процедур (RPC)
Производительность	Быстрее благодаря кэшированию и меньшему размеру сообщений	Медленнее из-за избыточного объёма передаваемых сообщений
Гибкость	Проще масштабировать и вносить изменения. Сервер не сохраняет состояние клиента	Сложнее масштабировать и вносить изменения. Сервер должен сохранять состояние каждого клиента
Обработка ошибок	Использует коды состояний HTTP для обозначения ошибок и успехов	Использует свои собственные коды состояний и XML-сообщение Retry
Простота	Проще и более "человекоориентирован". Не привязан к XML и чаще всего не требует WSDL или других файлов описания сервиса	Сложнее, требует глубокого понимания всех задействованных протоколов и их строгих правил. Работает только с XML. Требует описания WSDL для каждого сервиса
Раскрытие API	Не имеет языка описания веб-сервисов. Может использовать Swagger (OpenAPI) для документации	Всегда должен иметь WSDL, который даёт чёткие правила, как отправлять и принимать запросы
Безопасность	Не предусматривает никаких специальных мер безопасности. Может быть обеспечена только за счёт HTTPS или других механизмов аутентификации	Интегрированное расширение безопасности — WS Security, которое регулирует процедуры аутентификации и авторизации при обмене сообщениями
Использование	Используется повсеместно для создания современных веб-приложений и мобильных приложений	Применяется в системах, где нужна жёсткая стандартизация, а также в legacy

Определение​

Протокол​

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

Подход к API​

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

Гибкость​

Простота​

Обработка ошибок​

Раскрытие API​

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

Использование​

📌 Выводы​

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

📎 Полезные материалы​