Сравнение SOAP и REST с JSON [2019]

7 min readJan 21, 2019

Эта статья была в последний раз обновлена в январе 2019 года.

Веб-сервисы отвечают за интерактивное межмашинное взаимодействие. Компьютеры используют их для общения друг с другом через Интернет. Фактически, это только интерфейсные интерфейсы веб-сайтов и приложений, которые находятся на устройствах конечных пользователей.

Связанные данные хранятся на удаленном сервере и передаются на клиентский компьютер через API, которые предоставляют веб-сервисы сторонним пользователям. API могут использовать разные архитектуры для передачи данных с сервера на клиент.

Долгое время SOAP был протоколом обмена сообщениями, который использовался почти всеми веб-службами. Поскольку в наши дни разработчикам необходимо создавать легкие веб-приложения и мобильные приложения, более гибкая архитектура REST быстро завоевала популярность. В 2018 году большинство общедоступных веб-служб предоставили API-интерфейсы REST и передавали данные в компактном и простом в использовании формате обмена данными JSON. Однако корпоративные пользователи все еще часто выбирают SOAP для своих веб-сервисов. То же самое произойдет и в 2019 году.

Основные различия между SOAP и REST

SOAP и REST позволяют создавать собственный API. API означает интерфейс прикладного программирования. Это позволяет передавать данные из приложения в другие приложения. API получает запросы и отправляет ответы через интернет-протоколы, такие как HTTP, SMTP и другие. Многие популярные веб-сайты предоставляют общедоступные API-интерфейсы для своих пользователей, например, Google Maps имеет общедоступный REST API, который позволяет настраивать Google Maps с вашим собственным контентом. Есть также много API, которые были созданы компаниями для внутреннего использования.

SOAP и REST — это два стиля API, которые подходят к вопросу передачи данных с другой точки зрения. SOAP — это стандартизированный протокол, который отправляет сообщения с использованием других протоколов, таких как HTTP и SMTP. Спецификации SOAP являются официальными веб-стандартами, которые поддерживаются и разрабатываются Консорциумом World Wide Web (W3C). В отличие от SOAP, REST — это не протокол, а архитектурный стиль. Архитектура REST устанавливает набор рекомендаций, которым необходимо следовать, если вы хотите предоставить веб-службу RESTful, например, существование без сохранения состояния и использование кодов состояния HTTP.

Поскольку SOAP является официальным протоколом, он поставляется со строгими правилами и расширенными функциями безопасности, такими как встроенная совместимость с ACID и авторизация. Более высокая сложность требует большей пропускной способности и ресурсов, что может привести к снижению времени загрузки страницы. REST был создан для решения проблем SOAP. Поэтому у него более гибкая архитектура. Он состоит только из простых рекомендаций и позволяет разработчикам реализовывать рекомендации по-своему. Он допускает различные форматы сообщений, такие как HTML, JSON, XML и простой текст, в то время как SOAP допускает только XML. REST также является более легкой архитектурой, поэтому веб-сервисы RESTful имеют более высокую производительность. Из-за этого он стал невероятно популярным в эпоху мобильных устройств, где даже несколько секунд имеют большое значение (как по времени загрузки страницы, так и по доходам).

Что означает REST?

REST расшифровывается как представительский государственный трансферт. Это архитектурный стиль, который определяет набор рекомендаций для разработки слабосвязанных приложений, использующих протокол HTTP для передачи данных. REST не предписывает, как реализовать принципы на более низком уровне. Вместо этого, рекомендации REST позволяют разработчикам реализовывать детали в соответствии со своими потребностями. Веб-сервисы, созданные в соответствии с архитектурным стилем REST, называются веб-сервисами RESTful.

Чтобы создать REST API, необходимо соблюдать шесть архитектурных ограничений:

Унифицированный интерфейс — запросы от разных клиентов должны выглядеть одинаково, например, один и тот же ресурс не должен иметь более одного URI.
Разделение клиент-сервер — клиент и сервер должны действовать независимо друг от друга. Они должны взаимодействовать друг с другом только через запросы и ответы.
Безгражданство — не должно быть никаких сеансов на стороне сервера. Каждый запрос должен содержать всю информацию, которую сервер должен знать.
Кэшируемые ресурсы — ответы сервера должны содержать информацию о том, кэшируются ли отправляемые ими данные или нет. Кэшируемые ресурсы должны поступать с номером версии, чтобы клиент мог не запрашивать одни и те же данные более одного раза.
Многоуровневая система. Между клиентом и сервером, который возвращает ответ, может быть несколько уровней серверов. Это не должно влиять ни на запрос, ни на ответ.
Код по запросу [необязательно] — когда это необходимо, ответ может содержать исполняемый код (например, JavaScript в ответе HTML), который может выполнить клиент.

Какая основная причина использовать REST?

В 2018 году REST стал самым популярным выбором разработчиков для создания общедоступных API. Вы можете найти множество примеров по всему Интернету, тем более что все крупные сайты социальных сетей предоставляют API-интерфейсы REST, так что разработчики могут легко интегрировать свои приложения с платформой. Эти публичные API также поставляются с подробной документацией, где вы можете получить всю информацию, необходимую для извлечения данных через API.

Например, в Twitter есть несколько общедоступных API-интерфейсов REST, которые служат различным целям, например, API-интерфейс поиска, с помощью которого вы можете находить исторические твиты, API-интерфейс Direct Message, с помощью которого вы можете отправлять персонализированные сообщения, и API-интерфейс рекламы, с помощью которого вы можете программно управлять своими рекламными кампаниями. WordPress REST API является еще одним популярным примером для REST API. Он предоставляет конечные точки для типов данных WordPress, так что вы можете удаленно взаимодействовать с содержимым сайта WordPress и достигать замечательных результатов, таких как создание мобильных приложений с WordPress .

Согласно скандинавским API , REST почти всегда лучше для веб-API, так как он предоставляет данные в виде ресурсов (например user), а не сервисов (например getUser), как работает SOAP. Кроме того, REST наследует HTTP операции, то есть вы можете сделать простые вызовы API , используя хорошо известные HTTP глаголы , как GET, POST, PUTи DELETE.

REST и JSON

Архитектура REST позволяет поставщикам API доставлять данные в различных форматах, таких как простой текст, HTML, XML, YAML и JSON, что является одной из его самых любимых функций. Благодаря растущей популярности REST, легкий и читаемый человеком формат JSON также быстро завоевал популярность, так как он отлично подходит для быстрого и безболезненного обмена данными.

JSON означает JavaScript Object Notation. Это простой для анализа и легкий формат обмена данными. Несмотря на свое название, JSON полностью независим от языка, поэтому его можно использовать с любым языком программирования, а не только с JavaScript. Его синтаксис является подмножеством стандарта ECMA-262, 3-е издание . Файлы JSON состоят из наборов пар имя / значение и упорядоченных списков значений, которые представляют собой универсальные структуры данных, используемые большинством языков программирования. Поэтому JSON может быть легко интегрирован с любым языком.

Чтобы увидеть разницу между XML и JSON, вот пример кода из документов API Crowd Serverкомпании Atlassian, который позволяет запрашивать и принимать данные в форматах XML и JSON:

<?xml version="1.0" encoding="UTF-8"?>
<authentication-context>
   <username>my_username</username>
   <password>my_password</password>
   <validation-factors>
     <validation-factor>
       <name>remote_address</name>
       <value>127.0.0.1</value>
     </validation-factor>
   </validation-factors>
</authentication-context>

Вот как выглядит приведенный выше XML-код в JSON:

{
   "username" : "my_username",
   "password" : "my_password",
   "validation-factors" : {
      "validationFactors" : [
         {
            "name" : "remote_address",
            "value" : "127.0.0.1"
         }
      ]
   }
}

Как видите, JSON является более легким и менее многословным форматом, а также его легче читать и писать. В большинстве случаев он идеально подходит для обмена данными через Интернет. Тем не менее, XML по-прежнему имеет некоторые преимущества . Например, XML позволяет размещать метаданные в тегах, а также лучше обрабатывать смешанный контент, особенно когда массивы смешанных узлов требуют подробных выражений.

Что означает SOAP?

SOAP означает простой протокол доступа к объектам. Это протокол обмена сообщениями для обмена данными в децентрализованной и распределенной среде. SOAP может работать с любым протоколом прикладного уровня, таким как HTTP, SMTP, TCP или UDP. Он возвращает данные получателю в формате XML. Безопасность, авторизация и обработка ошибок встроены в протокол и, в отличие от REST, не предполагают прямой связи точка-точка. Поэтому он хорошо работает в распределенной корпоративной среде.

SOAP следует формальному и стандартизированному подходу, который определяет, как кодировать XML-файлы, возвращаемые API. На самом деле сообщение SOAP — это обычный XML-файл, состоящий из следующих частей:

Конверт (обязательно) — это начальный и конечный теги сообщения.
Заголовок (необязательно) — содержит необязательные атрибуты сообщения. Это позволяет расширять сообщение SOAP модульным и децентрализованным способом.
Тело (обязательно) — содержит данные XML, которые сервер передает получателю.
Неисправность (необязательно) — содержит информацию об ошибках, возникших при обработке сообщения.

Вот как выглядит обычное SOAP-сообщение. Пример взят из документов W3C SOAP и содержит конверт SOAP, блок заголовка и тело:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
  <env:Header>
    <n:alertcontrol xmlns:n="http://example.org/alertcontrol">
      <n:priority>1</n:priority>
      <n:expires>2001-06-22T14:00:00-05:00</n:expires>
    </n:alertcontrol>
  </env:Header>
  <env:Body>
    <m:alert xmlns:m="http://example.org/alert">
      <m:msg>Pick up Mary at school at 2pm</m:msg>
    </m:alert>
  </env:Body>
</env:Envelope>

Какая основная причина использовать SOAP?

В 2019 году SOAP, вероятно, продолжит использоваться для веб-сервисов уровня предприятия, которые требуют высокой степени безопасности и сложных транзакций. API-интерфейсы для финансовых услуг, платежных шлюзов, программного обеспечения CRM, управления идентификацией и телекоммуникационных услуг являются широко используемыми примерами SOAP. Одним из наиболее известных API-интерфейсов SOAP является общедоступный API- интерфейс PayPal, который позволяет принимать платежи через PayPal и кредитные карты, добавлять кнопку PayPal на ваш веб-сайт, разрешать пользователям входить в систему через PayPal и выполнять другие действия, связанные с PayPal.

Поддержка устаревших систем — еще один частый аргумент в пользу использования SOAP . У популярных веб-сервисов, которые существуют некоторое время, может быть много пользователей, которые все еще подключаются к своим сервисам через свой SOAP API, который был лидером рынка до того, как REST приобрел популярность. Например, Salesforce предоставляет API-интерфейсы SOAP и REST, так что каждый разработчик может интегрировать Salesforce со своей собственной платформой таким образом, который подходит им наилучшим образом.

Кроме того, SOAP может быть отличным решением в ситуациях, когда вы не можете использовать REST. Хотя в наши дни большинство провайдеров веб-услуг хотят обмениваться запросами и ответами без учета состояния, в некоторых случаях вам может потребоваться обрабатывать операции с состоянием. Это происходит в сценариях, в которых цепочка операций должна действовать как одна транзакция, например, в случае банковских переводов. Хотя API-интерфейсы SOAP по умолчанию не имеют состояния, SOAP поддерживает операции с состоянием, которые могут быть реализованы с использованием спецификаций WS- * (веб-сервисов) , основанных на основных стандартах XML и SOAP.

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

Хотя REST очень популярен в наши дни, SOAP по-прежнему занимает свое место в мире веб-сервисов. Чтобы помочь вам выбрать между ними, вот сравнительная таблица SOAP и REST, которая выделяет основные различия между двумя стилями API:

https://gist.github.com/nanotexnolagiya/8d27d4e4653c23193ebd479a6a6fbfa8#file-gistfile1-txt