Чем различаются REST и SOAP, и можно ли их вообще сравнивать?

Часто в вакансиях можно обнаружить требования по «знанию REST API и SOAP API», иногда – с вариациями вроде «RESTful API». Видимо, из-за этого у многих начинающих и возникает вопрос: что это вообще за технологии и какая между этими API разница. Проблема кроется в том, что за простым словом «API» скрываются целые архитектуры, и с учетом этого сталкивать лбами REST vs SOAP не очень корректно, так как эти технологии достаточно сильно отличаются. Ниже – о том, чем именно они отличаются и в чем их все же можно сравнивать.

Что такое SOAP?

Пойдем в историческом порядке – начнем с SOAP. SOAP – это Web API, то есть принцип построения веб-интерфейсов, с помощью которых разные приложения могут общаться друг с другом. Самая распространенная версия – SOAP 1.2. SOAP – это протокол обмена данными, и эта формулировка будет важна в дальнейшем. Что она значит?

Протокол – это четкий формат обмена информацией, которому должны все участники этого обмена. Если вы хотите послать на какой-то сервис запрос – вам нужно изучить документацию по SOAP и изучить документацию по взаимодействию с сервером, из них вы узнаете, что и в каком формате нужно передать серверу, чтобы получить интересующий вас ответ. SOAP полностью построен на формате XML – то есть все запрос должны переводиться в этот формат, все ответы тоже приходят в этом формате. В SOAP и запросы, и ответы засовываются в XML-пакеты, пакет – это законченная и полностью самостоятельная единица информации. Вот как выглядит XML-пакет авторизации (запрос на сервер):

Если авторизация прошла успешно – сервер тоже присылает XML-пакет с подтверждением:

Поскольку в SOAP данные передаются изолированными XML-пакетами, SOAP API вообще никак не зависит от протокола передачи данных – пакет можно передать по протоколу HTTP, FTP, TCP/UDP и так далее, передавать можно хоть по протоколам канального уровня, если вам это зачем-то пригодится. Кроме того, SOAP поддерживает возможность практически бесконечного расширения действий, которые может совершить сервер – главное, чтобы веб-сервис понял, что от него требуется, а добавить еще одну строчку в XML – вообще не проблема.

Что такое REST?

SOAP как Web API вырос из протокола передачи данных внутри крупных компаний, и когда интернет стал разрастаться, в SOAP обнаружилась большая проблема: слишком много лишних данных. Пакеты по протоколу HTTP сами по себе содержат мета-данные, и приходилось в HTTP-пакет с метаданными помещать SOAP-пакет со своими метаданными – получалось очень тяжело и медленно. Для того, чтобы обойти проблему, разработчики придумывали свои протоколы (некоторые из них живы до сих пор) – а потом, абсолютно внезапно, появился REST.

Если SOAP был протоколом передачи данных, строго определяющим формат передаваемых данных, то REST пошел дальше – он предложил архитектуру веб-приложений, то есть SOAP отвечает на вопрос: «В каком формате передать данные?», а REST отвечает на вопрос: «Как создать приложение, которые будет наиболее эффективно передавать данные?». Да, в REST тоже есть правила форматирования данных, кроме того – есть и правила, ограничивающие запрашиваемые действия (стандартные в HTTP)/ответы сервера (коды). Но все это касается только одного принципа (единообразие интерфейса), а всего принципов у REST – 6:

1. Клиент-серверная модель. Клиент и сервер должны быть разделены, суть API – во взаимодействии между клиентом и сервером.
2. Stateless. Сервер не хранит информацию о прошлых запросах клиента, то есть клиент с каждым новым запросом должен подавать всю информацию, необходимую для проведения действия.
3. Кэширование. Если серверу часто приходит один и тот же запрос – сервер должен кэшировать ответ, то есть сохранить его где-то у себя в кэше или локально у клиента, и обновить при необходимости.
4. Единообразие интерфейса. Ресурсы предоставляются в согласованном формате (обычно в формате JSON) и в полном объеме, каждое сообщение – самоописываемое, в ответе сервера на запрос действия с ресурсом должен содержаться не только результат выполнения запроса, но и перечень других действий с этим ресурсом.
5. Многоуровневость. Сервер должен быть многоуровневым – иметь прокси и балансировщик нагрузки, кэширование, модуль безопасности и все другое, что может ему понадобиться. Все это должно быть скрыто от клиента – клиенту показывается только точка доступа к серверу.
6. Код по запросу (опциональный принцип). Сервер может в ответ на запрос послать исполняемый кусок кода (обычно – JS).

Если сервис соблюдает 5 основных принципов, его называют RESTful-сервисом.

Сравнение: в чем похожи, в чем отличаются, насколько корректно сравнивать

Сравнивать SOAP vs REST – некорректно, поскольку SOAP – протокол обмена информацией, а REST – архитектура для построения API. Единственное сходство между ними – в том, что оба подхода как-то стандартизируют формат передачи данных, но даже здесь они сильно отличаются:

• SOAP: передавать данные нужно в XML-пакетах, делать это можно по любому протоколу передачи данных (в том числе по протоколам транспортного уровня), при желании можно добавить любое действие, которое поддерживает сервер.
• REST: передавать данные можно в любом формате (обычно используется JSON), делается это почти всегда через HTTP (передавать информацию через другие протоколы не имеет смысла), список вызываемых действий ограничен CRUD (create, read, update, delete).

Ну и, собственно, на этом сравнение заканчивается, потому что мы не можем спросить, например: «Где больше раскрыта тема кэширования – в REST или в SOAP?», потому что нет такой темы в SOAP.

Единственное, о чем еще в рамках «противопоставления» можно поговорить – где лучше использовать REST/SOAP? В целом все просто: если у вас нет четкой уверенности, что вам нужен SOAP – используйте REST, потому что последний даст вам и скорость, и готовый архитектурный подход (в случае с SOAP архитектуру будете продумывать сами). SOAP может понадобиться в следующих ситуациях:

1. Крайне высокие требования по безопасности. REST – безопасный API, но если «закручивать гайки», то чем больше в их будете закручивать, тем сложнее будет это делать. С помощью SOAP безопасность можно ужесточать до бесконечности.
2. Нужна целостность сессий/данных. SOAP позволяет создать сложную схему валидации («рукопожатий») и проверки целостности данных, в то время как REST обычно работает по принципу: «Не дошло? Ну еще раз отправлю, там посмотрим».
3. Вам нужно поддерживать легаси. Возможно, вы пишете новый модуль в большом и старом проекте, в котором все построено на SOAP – что ж, придется смириться и использовать его в качестве API.

Альтернативы SOAP и REST

REST и SOAP – не единственные Web API, которые существуют на этой планете. В основном другие API требуются тем разработчикам, для которых REST оказывается либо слишком медленными, либо слишком ненадежным. API – много, но для примера выделим 3 других популярных:

• WebSockets. API с прямой мгновенной передачей данных от сервера к клиенту – как только у сервера появились новые данные, он тут же их отправляет. Крайне нужная вещь, если вы разрабатываете онлайн-игру или стриминговый сервис.
• RPC. Удаленный вызов функций – вы добавляете функции другого сервера в локальную среду и выполняете их «как-бы на своей стороне». Тоже крайне быстрая в работе вещь, но писать ее – сложно, нужно учить отдельный язык. Кроме того, есть несколько десятков видов RPC, и вам нужно будет разобраться, чем они отличаются и какой именно вам нужен.
• GraphQL. Крайне легковесная API – никакой лишней информации, передается только то, что нужно. Хорошо подходит для социальных сетей и приложений с обновляемыми лентами.

Кратко о главном

• SOAP – это протокол обмена запросами.
• REST – это архитектурный подход для построения API.
• Сравнивать SOAP и REST – это как сравнивать лист с деревом: REST – намного более комплексная вещь, чем SOAP. В том числе нужно помнить, что основной вопрос SOAP – формат передачи информации – в REST является только одним из пунктов.
• REST – доминирующий подход к API сейчас, и в большинстве случаев нужно использовать именно его. SOAP может понадобиться только в некоторых случаях – вы поддерживаете легаси, вам нужна валидация информации или у вас очень жесткие требования к безопасности. Иногда стоит присмотреться к другим, более специфичным API – RPC, WebSockets, GraphQL и другим.