Каждый раз, когда вы входите на веб-сайт со своей учетной записью Facebook или перетаскиваете значок выпадающего списка по карте Google в приложении для вызова водителя, используемое вами приложение связывается с Google или Facebook через веб-API. API или интерфейс прикладного программирования - это форма соглашения между веб-службами о том, как они собираются обмениваться данными, например получить карту или учетные данные вашей учетной записи. Сами данные структурированы в сообщениях, которые системы отправляют друг другу. Как только вы откроете, скажем, приложение Uber, ваш телефон отправит запрос сообщения в Google Maps, а Google вернет саму карту.

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

В этой статье мы выясним, как работает протокол SOAP, почему он так распространен среди корпоративных пользователей и чем отличается от REST.

Пора сделать несколько предостережений: в этой статье используются такие технические термины, как сервер, клиент, протоколы и т. Д. Несмотря на то, что большинство из них объяснены, если вы все еще не уверены, взгляните на нашу статью о веб-архитектуре для начинающих. . Это удобная отправная точка для тех, кто просто пытается погрузиться в воду.

Что такое SOAP?

SOAP или Протокол доступа к простым объектам - это протокол веб-связи, разработанный для Microsoft еще в 1998 году. Сегодня он в основном используется для предоставления веб-сервисов и передачи данные через HTTP / HTTPS. Но ими дело не ограничивается. SOAP, в отличие от шаблона REST, поддерживает только формат данных XML и строго следует предустановленным стандартам, таким как структура обмена сообщениями, набор правил кодирования и соглашение о предоставлении процедурных запросов и ответов.

Встроенные функции для создания веб-сервисов позволяют SOAP обрабатывать сообщения и делать ответы независимыми от языка и платформы.

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

SOAP работает только с XML

Данные, передаваемые через Интернет, обычно имеют определенную структуру. Два самых популярных формата данных - это XML и JSON.

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

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

Помимо формата данных, SOAP имеет еще один уровень стандартизации - структуру сообщений.

Структура сообщения SOAP

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

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

Заголовок (необязательно) определяет специфику, дополнительные требования к сообщению, например аутентификация.

Тело включает запрос или ответ.

Ошибка (необязательно) показывает все данные о любых ошибках, которые могут возникнуть в запросе и ответе API.

Расширяемость SOAP с помощью стандартных протоколов WS

При этом сам протокол SOAP предоставляет основные структурные элементы сообщения. Но он не определяет, что должно быть в заголовках и теле. В принципе, вы можете настроить это содержимое по своему усмотрению.

Но поскольку веб-приложения обычно решают общие наборы проблем, после выпуска SOAP основной протокол был дополнен многочисленными стандартными протоколами, которые определяют, как вы это делаете. Все эти протоколы обычно имеют пометку WS- (название протокола), например. WS-Security, WS-ReliableMessaging. Они были предоставлены различными организациями, включая Microsoft, IBM, OASIS и другие.

Стандартные протоколы охватывают несколько областей и аспектов использования SOAP:

  • Безопасность
  • Обмен сообщениями
  • Сделки
  • Метаданные и т. Д.

Эти протоколы хороши тем, что вы можете выбирать, какой из них использовать. Обычно это называют расширяемостью SOAP. Например, если вам нужно, чтобы ваши финансовые транзакции были безопасными, вы можете применить WS-Atomic Transaction, которые совместимы с ACID.

Соответствие ACID

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

Соответствие ACID означает, что транзакции соответствуют следующим требованиям:

Атомарность. Несколько связанных транзакций либо работают как единое целое, либо не работают вообще. Иногда это называют подходом все или ничего. Этот набор транзакций сравнивается с атомом, который состоит из нескольких тесно связанных элементов.

Последовательность. Если какая-то часть транзакции не удалась, система возвращается в исходное состояние.

Изоляция. Транзакции независимы друг от друга.

Долговечность. Даже если система выйдет из строя, завершенные транзакции останутся.

Если вы используете WS-Atomic Transaction, еще один стандартный протокол, вы сможете добиться соответствия требованиям ACID.

Документ на языке описания веб-сервисов (WSDL)

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

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

В WSDL замечательно то, что он позволяет генерировать клиентский код на разных языках и сразу же отправлять сообщения серверу. Хотя не все API-интерфейсы SOAP используют документы WSDL, их использование настолько популярно, потому что помогает различным языкам программирования и IDE быстро наладить взаимодействие.

Подробнее о технической документации в нашей специальной статье.

Протоколы передачи: HTTP, TCP, SMTP, FTP и др.

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

SOAP поддерживает множество протоколов передачи, как высокого, так и низкого уровня. Например, SOAP позволяет обмениваться сообщениями через TCP (протокол управления транзакциями), низкоуровневый метод обмена данными, который работает между портами через IP-сеть. Вы можете выбрать вариант SMTP (простой протокол передачи почты), который представляет собой протокол связи для передачи электронной почты, FTP (протокол передачи файлов) и любой другой метод передачи, поддерживающий обмен текстовыми данными.

Имеет ли смысл отправлять данные по протоколам, отличным от HTTP / HTTPS? В большинстве случаев это не так. SOAP в первую очередь был разработан для работы с HTTP. Но могут быть сценарии, такие как ограничения безопасности, требования к серверу, архитектура решения или просто скорость, которые выиграют от этой универсальности SOAP.

SOAP WS-Безопасность

SOAP ценится за способность интегрировать функцию WS-Security. Этот набор протоколов определяет, как обеспечить безопасность внутри транзакций, и предлагает конфиденциальность и целостность данных. Кроме того, он позволяет использовать шифрование и криптографическую подпись.

WS-Security позволяет шифровать ваши сообщения не только по протоколу HTTPS (который уже содержит шифрование), но и на уровне сообщения, имея данные аутентификации в элементе заголовка. Необходимо убедиться, что если ваши данные выходят за пределы HTTPS, когда достигают сервера, они могут быть прочитаны только правильным процессом внутри этого сервера, а не самим правильным сервером. Поскольку на стороне сервера может произойти некоторая предварительная обработка данных до того, как сообщение достигнет назначенного процесса.

Витторио Берточчи, главный программный менеджер Microsoft, объяснил, как работает WS-Security, используя метафору голого мотоциклиста.

Представьте свое сообщение в виде обнаженного мотоциклиста. Чтобы добраться до места назначения, он может проехать через прозрачный туннель и надеяться, что его никто не увидит (HTTP). Или он может проехать через непрозрачный туннель. В этом случае, хотя никто не видит его, когда он находится внутри туннеля, чтобы добраться до конечного пункта назначения, он все равно должен проехать по некоторым улицам (HTTPS, очевидно, непрозрачный туннель). И, наконец, он может просто носить одежду и шлем, чтобы чувствовать себя в полной безопасности (WS-Security).

Благодаря этой безопасности на уровне сообщений финансовые организации и другие корпоративные пользователи выбирают протокол SOAP.

Обмен сообщениями SOAP с отслеживанием и без сохранения состояния

Начало 21 века запомнилось интернет-бумом. Появлялись тысячи интернет-компаний, и миллионы пользователей выходили в Сеть каждый день. А теперь представьте, что один сервер начинает одновременно получать тысячи запросов от пользователей (клиентов). И если этот ресурс делает что-то более сложное, чем отображение стен текста, все может замедлиться. Например, если пользователи проверяют расписание предстоящих рейсов и должны детализировать каждую деталь полета, сервер должен знать, что происходит с клиентом, верно?

Похоже, что вы можете справиться с этой ситуацией двумя способами: используя операции с сохранением состояния и без сохранения состояния. И SOAP поддерживает и то, и другое.

Stateful означает, что сервер сохраняет информацию, которую он получает от клиента, по нескольким запросам. Например, сначала он запоминает даты полета, которые вы ищете, а затем предоставляет информацию о ценах после второго запроса. Это позволяет объединять сообщения в цепочку, сообщая серверу о предыдущих запросах. Обмен сообщениями с отслеживанием состояния может иметь решающее значение в операциях с участием нескольких сторон и сложных транзакциях, например банковские операции или бронирование авиабилетов. Но все же для сервера это действительно тяжело.

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

Операции с отслеживанием состояния - одна из причин, по которой протокол SOAP используется для банковских транзакций и другого обмена данными, который требует объединения сообщений. Подробнее о вариантах использования SOAP ниже.

Логика повтора

При создании SOAP API разработчики могут интегрировать логику успешного выполнения / повторной попытки. Проще говоря, если что-то пойдет не так, запрашивающая сторона получит сообщение XML с кодом ошибки и ее объяснением. Таким образом, разработчик на стороне клиента понимает причину сбоя и может настроить запрос, чтобы получить успешный ответ. Эта функция добавляет уверенности в процессе разработки, поскольку вам не нужно вручную искать проблему. SOAP имеет спецификацию по умолчанию для определения формата ответа.

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

Некоторые недостатки SOAP, которые следует учитывать

Ресурсоемко. Из-за большего размера XML-файла и полезной нагрузки, создаваемой массивной структурой сообщения, SOAP API требует большей пропускной способности. Иногда с этим компромиссом не стоит иметь дела. Проще говоря, эти строки тегов, которыми изобилуют сообщения XML, обрабатываются медленно.

Трудное обучение. Поскольку построение серверов SOAP API основано на протоколах, требуется знание и понимание всех протоколов, которые вы можете с ним использовать. Разработчики, занимающиеся созданием этих типов API, должны глубоко погрузиться во все процессы внутри протокола с его строго ограниченными правилами.

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

Начало работы с SOAP: основные источники

Если вы только начинаете разработку SOAP, вот основные ссылки, которые вам следует проверить:

Документация по SOAP - ключевой источник истины для начинающих работать с SOAP.

Версии SOAP - поскольку было несколько итераций протокола, проверьте эти версии SOAP.

WSDL - как использовать язык описания веб-сервисов и создавать документы WSDL

WS-Addressing - как добавить информацию о маршрутизации в заголовки SOAP

WS-ReliableMessaging - расширение, чтобы сообщения приходили по назначению. Это также помогает создавать цепочки сообщений.

WS-Coordination - согласование действий распределенных приложений.

WS-Security - как включить защиту на уровне сообщений

WS-Atomic Transaction - как сделать сообщения ACID-совместимыми

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

Описывая SOAP, нельзя не упомянуть его основную альтернативу - REST.

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

REST был представлен в 2000 году - он ненамного моложе SOAP - с целью заставить серверы меньше заботиться о том, что происходит на клиенте.

И вот здесь начинается одно из основных различий между REST и SOAP.

Операции с отслеживанием и без сохранения состояния. REST не имеет гражданства; SOAP поддерживает оба подхода.

Структура сообщения. Хотя сообщение SOAP представляет собой «конверт», сообщение REST находится на «открытке»: оно не имеет дополнительных упаковок, заголовков или чего-либо еще, что могло бы изменить его упрощенный характер.

Разоблачение логики. В отличие от протокола SOAP, который сохраняет свою логику в документе WSDL, у REST есть альтернатива - документ WADL (или документ языка описания веб-приложений). Он не так распространен, как WSDL, но иногда он полезен, если вы работаете в корпоративной среде и не можете легко связаться с людьми со стороны службы, требуя, чтобы у вас были под рукой некоторые формальные соглашения.

Форматы данных. Как мы уже упоминали, SOAP - это строго XML. REST может работать с JSON, XML, HTML и другими форматами, которые вам нравятся. Но самым популярным остается JSON (или объектная нотация JavaScript).

Протоколы передачи. SOAP является гибким с точки зрения протоколов передачи, что позволяет использовать его в различных сценариях. REST ориентирован исключительно на обмен HTTP / HTTPS. Могут быть некоторые исключения, если вы сопоставляете методы обмена HTTP (GET, POST PUT, DELETE и т. Д.), Скажем, с методами FTP. Но REST был разработан с учетом HTTP.

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

Размер сообщения. Отсутствие служебного текста и блоков кода в простом файле JSON по сравнению с громоздким XML в SOAP приводит к значительному уменьшению размера. Другими словами, скромный файл JSON RESTful API легче и быстрее обрабатывать и передавать.

Кривая обучения. Архитектура RESTful проста и понятна. SOAP требует более глубокого понимания стандартов и дополнительных протоколов WS. Вдобавок ко всему, инженерное сообщество, занимающееся REST, шире. Таким образом, вы можете рассчитывать найти ответы на проблемы намного быстрее.

Обработка ошибок. В отличие от SOAP API, спецификация которого позволяет возвращать сообщение Retry XML с кодом ошибки и ее объяснением, REST API оставляет меньше места для прозрачности. REST в основном предоставляет два варианта: Ответ может содержать код ошибки без каких-либо объяснений. Это функция по умолчанию. С другой стороны, технология позволяет вручную прописывать объект ошибки вместе с его кодом.

Безопасность. REST API использует Secure Sockets Layer (или SSL) вместе с HTTPS поверх HTTP, имея простой транспортный механизм в качестве метода шифрования. Покрытие HTTPS действует как щит для безопасности данных. Протокол безопасности SSL применяется через соединение HTTPS для проверки вызовов REST API. С помощью SOAP вы также можете использовать SSL, включая обмен сообщениями TCP, в дополнение к безопасности на уровне сообщений.

Примеры использования SOAP

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

Стандартизированные операции: биллинг, навигация, услуги. Все варианты использования, в которых необходимо исключить любую неверную интерпретацию, хорошо подходят для обмена данными по протоколу SOAP. Обычно эти системы имеют строгие контракты с четко определенной логикой, которую можно описать с помощью документа WSDL.

Банковские операции и платежные системы. Когда вам нужно, чтобы ваши транзакции всегда были надежными и недоступными для третьих лиц, SOAP имеет множество преимуществ, которые следует учитывать. Во-первых, это уровень безопасности с соблюдением требований ACID и протоколов WS-Security. Кроме того, для этого набора сценариев использования обычно требуется обмен сообщениями с отслеживанием состояния, т. Е. Использование связанных транзакций, которые не изолированы одна от другой. Поскольку платежные системы могут иметь несколько сторон, участвующих в одной операции, SOAP позволяет лучше координировать их действия.

Системы бронирования авиабилетов. Поскольку в бронировании билетов обычно участвует несколько сторон, некоторые провайдеры из этой отрасли по-прежнему полагаются на протокол SOAP для обработки сообщений с отслеживанием состояния и цепочки сообщений.

Обмен сообщениями, отличными от HTTP, и устаревшие среды. Если требования к серверу и существующие системы используют протоколы связи помимо HTTP, SOAP - это первый вариант, на который следует обратить внимание.

Эта статья является частью серии, в которой рассматриваются различные подходы к системам и стандартам цифровой связи. Вы также можете проверить:
Что такое API?

GraphQL

Электронный обмен данными (EDI)

Первоначально опубликовано в техническом блоге AltexSoft Что такое SOAP: форматы, протоколы, структура сообщений и чем SOAP отличается от REST »