Запросы soap: SOAP API — что это такое за протокол обмена структурированными сообщениями

Чтобы наглядно объяснить, что такое пространство имён, рассмотрим следующий пример.

Представьте себе, что по интернету ходят XML-документы, сформированные разными приложениями (собственно, так и происходит). Может случиться, что одно приложение использует тег table и второе тоже использует тег table, но уже совсем в другом смысле.

Например, в первом случае тег table — это текст, который используется в языке HTML для указания того факта, что дальше идет описание таблицы. А во втором — предназначен для того, чтобы описать африканский кофейный стол и его размеры.

Как сделать так, чтобы приложение определило, что это разные теги table?

XML-документы с тегом table

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

У себя дома имя мальчика Серёжи, скорее всего, является уникальным идентификатором. То есть, вероятнее всего, ни одного Серёжи в семье больше нет. Но когда Серёжа приходит в школу, он обнаруживает, что в классе ещё три Серёжи, и учителю их надо как-то различать.

Как это сделать? Как правило, в классе для этого используется фамилия ребенка. Но если в классе есть однофамильцы Серёжи? Что ж, и такое бывает. В этом случае отличать Серёж можно по их домашнему адресу.

Интересный момент: если учитель знает, что Серёжа Васильев живёт по этому адресу, а тут в класс приходит некая Аня Васильева, живущая по этому же адресу, то можно сделать логичный вывод, что, скорее всего, Серёжа и Аня — брат и сестра. Именно адрес и указывает учителю на то, какая это семья и где она живёт. В XML-документах точно такая же логика.

Если нам нужно определить пространство имён (семью), к которому относится тег, мы заводим специальный атрибут. Этот атрибут называется XML namespace, сокращенно xmlns. Именно в xmlns мы пишем адрес — то место, где публикуется стандарт стандарта языка (то есть в атрибуте xmlns указывается адрес документа, в котором явно описано, что такое table для документа HTML).

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

Что из себя представляет семья тегов?
Правило такое: если тег, у которого указано пространство имён, содержит вложенные теги, то эти вложенные теги относятся к тому же пространству имён.

То есть наш кофейный столик — это теги:

• name
• width
• lenght
• table

Все они из одного семейства тегов, как те самые Серёжа и Анна, которые относятся к одной семье.

Поэтому для того, чтобы идентифицировать теги, используется атрибут — атрибут пространства имён xmlns.

Пространство имён записывается как атрибут и это тоже узел дерева, только узел другого типа. У него также есть текстовое содержимое, только это особое текстовое содержимое. В целом, это тоже XML-документ просто узлы здесь разные (элементные и атрибутные).

Сообщения SOAP

Для эффективной работы нам, аналитикам, вполне достаточно знания основ синтаксиса XML. И для того, чтобы разбираться с SOAP, приведенных знаний будет достаточно. Если же вы захотите углубиться в детали, то про XML стоит читать в первоисточнике, то есть на сайте W3C.

Ранее в примерах мы говорили про обмен данными между сайтом и биржей акций. Как это происходит?

Чтобы отправить запрос в биржу акций, нужно ответить на простой вопрос. Facebook и сайт биржи акций должны ответить «252.36» — это содержимое, которое надо передать. Протокол SOAP предполагает, что это текстовое содержимое вложено внутрь XML-тегов и прописано в стандарте в виде XML-дерева.

Запрос и ответ в виде дерева

Как мы видим, для того, чтобы сложить Facebook и отправить его в виде конверта, текст «Facebook» вкладывается в тег symbol. Тег symbol вкладывается в getQuote. Тег getQuote вкладывается в Body, а он в свою очередь, вкладывается в Envelope.

Запрос по протоколу SOAP

Давайте разберем на составляющие данный запрос.

Envelope и Body — теги, которые прописаны в протоколе SOAP. То есть, если вы отправляете запрос по протоколу SOAP, то у вас должен быть тег Envelope и вложенный в него тег Body. Это нужно просто запомнить.

SOAP-ENV — обозначение пространства имён, то есть теги Envelope и Body относятся к пространству имён SOAP-овского окружения и это не что иное, как краткое указание на то, что есть определенное семейство тегов. А где описывается пространство имён, мы разберем немного позже.

getQuote (получить котировку) — имя процедуры, которую мы хотим вызвать. Она относится уже к другому пространству имён, а именно «ns1».

«Faсebook» — это входной параметр, который мы передаем, и он завернут в тег Symbol. Обратите внимание на атрибут, который есть в этом теге «string» — он описывает, что передаваться должно не число, а строка.

Ответ по протоколу SOAP выглядит в виде дерева:

Ответ по протоколу SOAP

Согласно представленному дереву документов, ответ содержит «252.36». Он завернут в тег Result. A Result, в свою очередь, завернут в getQuoteResponse (ответ в котором содержится котировка акций). Далее getQuoteResponse завернут в Body, а тот в свою очередь — в Envelope.

Web Services Description Language (WSDL)

Давайте теперь вернемся к WSDL — документу, благодаря которому приложение заранее знает, какие должны прийти данные внутри каких тегов.

Основные теги с которыми вы столкнетесь в описании WSDL-сервера:

• Message — сообщения, используемые web-сервисом.
• PortType — список операций, которые могут быть выполнены с
• сообщениями.
• Binding — способ, которым сообщение будет доставлено.

WSDL-сервер

Как все это выглядит?
На веб-сервисе лежит файл WSDL. И клиент, и сервер руководствуются в своей работе этим файлом: читают его и разбираются, как устроен сервис. И клиент, и сервер умею читать этот файл и получать из него информацию, так как они знают стандарт SOAP и то, как должен быть устроен файл WSDL.

Давайте разберем этот wsdl-файл:

WSDL-файл

Operation — это тег, который описывает функции. То есть он указывает на имя функции и то, как должен выглядеть запрос и ответ.

Вложенные в operation теги input и output содержат информацию о входных и выходных параметрах функции. То есть getQuoteRequest — это запрос, который представляет собой строку и должен иметь вид числа с плавающей точкой.

Тег binding описывает все технические сведения, о том, что из себя представляет сервис.

Тег servisce описывает, где живет наш сервис. Если бы мы установили веб-сервисом на локальной машине, то адрес написали бы следующим образом: localhost/server1. php/.

Если вы захотите расписать WSDL в виде дерева, то получите следующую картину:

WSDL-файл в виде дерева

Корневой тег definitions содержит 2 тега message, описывающие входной и выходной параметры.

Далее идет тег portType, включающий в себя тег operation, который также описывает входной и выходной параметры. PortType же собирает вместе информацию из двух тегов message.

Тег binding описывает все технические особенности нашего сервера. Считается довольно сложным в прочтении для начинающих.

Тег service содержит описание нашего сервера.

Выводы

Главным недостатком SOAP является то, что при его использовании для передачи сообщений, он увеличивает их объём и снижает скорость обработки.
Мы смогли в этом убедиться на примере вопроса «Facebook» и ответа «252.36», которые требуют огромного количества тегов, в которые заворачивается вопрос.

Для того, чтобы еще раз сравнить SOAP и REST, я привела преимущества приложения, созданного на основании REST:

1. Надёжность (за счёт отсутствия необходимости сохранять информацию о состоянии клиента, которая может быть утеряна).
2. Производительность (за счёт использования кеша).
   
3. Масштабируемость.
   
4. Прозрачность взаимодействия между системами по сети.
   
5. Простота интерфейсов.
   
6. Портативность компонентов.
   
7. Лёгкость внесения изменений.
   
8. Способность эволюционировать, приспосабливаясь к новым требованиям.
   

Поясним несколько важных моментов. Если говорить о простоте интерфейсов, то разумеется REST проще, так как передает информацию в файле формата JSON, а формат JSON специально создан для языка JavaScript, на котором работает браузер.

Для SOAP необходимо специальное приложение, чтобы разобрать XML-документ, распарсить его, как говорят в ИТ-среде.

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

Курс Елены Бенкен

«Основы проектирования интеграций»

Курс для ИТ-аналитиков и проектировщиков, знакомых с техникой use cases (сценарии использования) и разработкой требований к качеству ПО,
которым необходимо разобраться в теме интеграций и
научиться проектировать взаимодействие ИТ-систем

Вопросы

• Вопрос:

  Как создать тег Biding?

  Ответ:

  Аналитик не должен озадачиваться тем, как создавать тег binding. Это должен делать программист биржи акций, если мы запрашиваем у нее WSDL, а не программист приложения, в котором мы используем этот WSDL (то есть не программист сайта биржи акций).

• Вопрос:

  Как записаться на курс по проектированию интеграций ИТ-систем?

• Вопрос:

  Как происходит асинхронное взаимодействие по протоколу SOAP? Например, отправлен запрос, он будет несколько минут обрабатываться. Отправляется ли сообщение о том, что запрос получен и взят в работу?

  Ответ:

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

Елена Бенкен

Системный аналитик, Автор курсов и Преподаватель

• Имеет опыт разработки ТЗ в тематике спутниковой связи, программ лояльности;
• Многолетний опыт участия в разработке навигационных систем для космических аппаратов, проектировании и макетировании микроэлектронных устройств;
• Автор учебных курсов по php, mysql, javascript, jquery, ajax, Linux;
• Написала и издала в BHV книги «PHP, MySQL, XML. Программирование для Интернета», «AJAX. Программирование для Интернета»;
• Выпускник Питерского политеха по специальности «физика космоса».

Подписаться на новые статьи

Что такое SOAP? — Stack Overflow на русском

Вот вам, например, надо передать некоторому серверному сценарию имена и значения переменных — такое происходит практически при каждом переходе по ссылке или после нажатию на кнопке формы. Выглядит это так:

http://www.server.ru/page.php?name=Vasya&age=20&sex=male&street=Gagarin%2013&city=Tashkent&country=Uzbekistan

Здесь передаются 6 переменных (name, age, sex, street, city и country) со своими значениями. page.php, в свою очередь, принимает эти значения и обрабатывает в соответствии с заданными инструкциями. Все эти переменные равны по статусу в цепочке и не описывают зависимость друг от друга (ниже поймете, что это означает). Тем более, даже если всего лишь логически рассматривать все 6 переменных как одну связку, то они описывают один объект, — т. е. некоторого индивидуума мужского пола, которого зовут Вася и которому 20 лет (и т.д), хотя

Понятно, что у этих 6-ти переменных нет описания зависимости друг от друга — но для того, чтобы показать зависимость и иерархию, надо что-то добавить…. И тогда приходит на помощь XML.

XML, как вам уже известно, предоставляет удобный синтаксис для описания иерархии данных. Формат вам уже знаком:

<person>
    <id>1000</id>
    <name>Vasya</name>
    <age>20</age>
    <sex>male</sex>
    <address>
        <street>Gagarin 13</street>
        <city>Tashkent</city>
        <country>Uzbekistan</country>
    </address>
</person>

В коде выше наглядно видны зависимость и иерархия. Единицей информации, описывающей 1 объект, является пространство от <person> до </person>, которое имеет вложенные элементы, расположенные по иерархии относительно <person> ниже. Вложенные элементы, как видно из <address>, тоже могут иметь свои вложенные элементы. Грубо говоря, пространство

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

А теперь усложним задачу: вам надо передать

<customers>
    <person>
        <id>1000</id>
        <name>Vasya</name>
        ....
    </person>
    <person>
        <id>1001</id>
        <name>Petya</name>
        ....
    </person>
</customers>

Но вот как организовать это с помощью конструкции name=Vasya&age=20&sex=male? Дважды имя переменной (хотя бы) name (одно для Васи, другое для Пети) ведь невозможно использовать в одной строке. .

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

P.S. Написано весьма условно и символически — целью ставил уровень специально для читателя, который, ознакомившись, пойдет по правильному руслу.

сообщений запросов и ответов SOAP | Documentation

Существует несколько панелей на выбор при работе с сообщениями SOAP Request и Response. Давайте посмотрим на оба.

Сообщения запроса

• XML — стандартное текстовое представление базового XML-сообщения, щелкните правой кнопкой мыши в редакторе, чтобы открыть всплывающее меню с соответствующими действиями:

  Выберите Подтвердить , чтобы проверить текущее сообщение на соответствие базовой схеме и отобразить список ошибок проверки внизу, если они обнаружены:

• Raw — отображает фактические байты последнего отправленного сообщения, включая заголовки HTTP, вложения MIME и т. д.:

  Используйте эту панель для проверки результатов раскрытия свойств, фильтров и т. д. Содержимое здесь должно быть таким же, как и в журнале HTTP в нижней части главного окна SoapUI:

  .

Отслеживание производительности тестирования по мере масштабирования тестирования API

Сравните: все функции SoapUI Pro

SoapUI с открытым исходным кодом

• Поддержка тестирования SOAP и REST API.
• Простое переключение между несколькими средами.
• Подробная история тестов и отчет о сравнении тестов.

SoapUI Pro

• Поддержка тестирования API SOAP, REST и GraphQL.
• Простое переключение между несколькими средами.
• Подробная история тестов и отчет о сравнении тестов.

• Редактор структуры — показывает древовидное представление базового XML-сообщения:

  В столбце справа показан тип схемы соответствующего значения.

  Здесь вы можете редактировать значения существующих элементов/атрибутов, но не можете добавлять или удалять существующие узлы в дереве.

• Форма — отображает удобную для пользователя форму ввода для базового запроса, значительно упрощая ввод содержимого, чем в редакторе XML:

  Опция View Type позволяет удалять ненужные элементы или элементы, не содержащие никаких данных. Это может быть полезно при ручном тестировании, если используются только определенные поля. В зависимости от типа поля ReadyAPI отображает различные редакторы, в том числе специальные редакторы для дат, времени, массивов, списков и так далее. Например, ниже скриншот редактора даты:

  Примечание: Хотя редактор поддерживает достаточно сложные XML-схемы, он не поддерживает все возможные конструкции XML-схем.

Вставка данных

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

Затем выбрать нужное свойство в последующем Диалоговое окно «Получить данные» :

Здесь мы выбираем свойство «Пароль», определенное на шаге теста «Свойства». После нажатия кнопки «Добавить» вы увидите следующее:

Ответные сообщения

Ответное сообщение имеет следующие панели:

• XML — показывает XML-содержимое ответного сообщения:

• Raw — показывает необработанные байты ответного сообщения:

• Редактор структуры — показывает ответное сообщение в виде дерева только для чтения:

• Обзорный редактор — показывает удобный для пользователя рендеринг ответа:

  URL-адреса в ответном сообщении кликабельны.

  Они будут открыты в браузере по умолчанию.

Следующие шаги

Вложения и файлы

Аутентификация запросов SOAP

Аутентификация SPNEGO/Kerberos

Операции и запросы

Заголовки HTTP

API SOAP | Пример протокола SOAP API | Интерфейс SOAP API

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

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

SOAP — это простой протокол доступа к объектам, стандарт обмена сообщениями, определенный консорциумом World Wide Web и его членами. редакторы. SOAP использует формат данных XML для объявления своих запросов и ответных сообщений, опираясь на XML-схему и другие технологии для обеспечения структуры своих полезных нагрузок.

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

SOAP использует шаблон удаленного вызова процедур (RPC), где функции или методы передаются в качестве параметров и возвращают результат. Многие решения RPC до SOAP зависели от конкретных языков программирования или технологических стеков. Для Например, предыдущие реализации RPC часто требовали, чтобы обе стороны RPC использовали язык программирования C, который предшествует современному Интернету. Даже язык эпохи Интернета, Java, имеет собственную модель RPC, называемую удаленным вызовом метода. (RMI), которая изначально была тесно связана с виртуальной машиной Java (JVM).

Одним из важных аспектов API-интерфейсов SOAP является их независимость от языка программирования и даже лежащего в основе транспорта. протокол. Отправитель может использовать, например, C#, в то время как стек получателя опирается на Java. В то время как эти более корпоративно-ориентированные языки наиболее распространены с SOAP, существуют реализации SOAP на Python, Ruby и всех современных языках. языки программирования.

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

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

Хотя в следующих примерах для удобства чтения используется Python, помните, что SOAP не зависит от вашего программирования. язык. Чтобы получить профиль пользователя из вымышленного API SOAP, вы можете сделать следующий запрос, используя Zeep библиотека:

В этом примере мы инициируем клиент SOAP на основе конечной точки SOAP. Затем мы вызываем сервис, вызывая опция getuser с параметром идентификатора пользователя. Это простой пример, но он скрывает еще больше деталей сообщений SOAP. за кулисами.

Давайте посмотрим, как может быть структурирован этот вызов SOAP:

И ответ может выглядеть примерно так:

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

Тем не менее, можно выполнять вызовы SOAP API с помощью типичного HTTP-запроса (большинство служб SOAP используют HTTP, хотя спецификация не зависит от протокола). Вот тот же вышеприведенный вызов с использованием библиотеки запросов Python:

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

В приведенных выше примерах уже показан формат сообщений SOAP API. В этом разделе вы можете лучше понимать несколько блоков XML, содержащихся в запросах SOAP. Хотя он преднамеренно минимален («S» в SOAP означает «простой», в конце концов), он обеспечивает основу для сложных реализаций.

Сообщения SOAP состоят из четырех блоков:

• soap:Envelope
• мыло:Заголовок
• мыло: корпус
• мыло: Ошибка

Только мыло : требуется конверт и мыло : корпус . Однако каждый из них играет важную роль в API-интерфейсах SOAP. Ниже каждый из эти конструкции SOAP рассматриваются отдельно.

Конверт SOAP

SOAP использует XML, но ему нужен способ отделить его от других документов XML. soap:бирка Envelope предоставляет механизм для определить XML как SOAP.

Кроме того, для тега soap:Envelope требуется атрибут namespace ( xmlns:soap="https://www.w3.org/2003/05/soap-envelope/" для последней версии SOAP) и может дополнительно предоставить атрибут encodingStyle .

Все сообщение SOAP находится внутри конверта, включая остальные три блока.

В базовых примерах API SOAP, показанных в предыдущих разделах, заголовок был пустым. Хотя это необязательно, 9Мыло 0169: Коллектор делает возможная расширяемость SOAP с помощью модулей SOAP. Эти модули могут быть обязательными или необязательными. В случае, если они требуются, вы можете включить атрибут mustUnderstand со значением true .

SOAP Body

Как следует из названия и показано в примерах, soap:Body содержит большую часть сообщения SOAP. Можно использовать пространства имен для описания того, какие данные ожидать в теле, но не требуются. На практике название процедуры, параметры и данные проходят через тело SOAP.

SOAP Fault

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

Чтобы сообщить о многих ошибках, в теге неисправности могут присутствовать несколько подэлементов:

• Код : машиночитаемый код ошибки
• Причина : удобочитаемая причина ошибки
• Узел : узел SOAP, на котором произошла ошибка
• Роль : роль узла SOAP, на котором произошла ошибка
• Detail : подробные сведения об ошибках для конкретного приложения, с данными, которые могут быть прочитаны человеком и машиной

Хотя soap:Fault является необязательным, реализация SOAP не будет действительно полной без инкапсуляции потенциальных ошибок с использованием этот тег.

По мере повсеместного распространения SOAP и других веб-служб для их поддержки было создано множество инструментов, технологий и стандартов. Среди них язык описания веб-служб (WSDL), формат XML, описывающий, как вызывать веб-службу. Это определяет доступные операции и ожидаемые поля ввода/вывода.

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

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

Как и SOAP, WSDL достаточно универсален для многих типов использования, хотя эти две технологии часто используются вместе.

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

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

Например, HTTP Basic Auth принимает имя пользователя и пароль. При отправке через SSL/TLS это может быть простым способом аутентифицировать пользователя. Однако в этом методе нет встроенной роли или авторизации. Кроме того, пока это обеспечивает двухточечную безопасность, часто требуется сквозная безопасность.

WS-Security — это расширение SOAP, предоставляющее ряд функций безопасности для API-интерфейсов SOAP. Построен на основе XML Спецификации шифрования и XML-подписи, WS-Security описывает, как подписывать и шифровать сообщения SOAP. Кроме того, он поддерживает несколько форматов маркеров безопасности, включая SAML, X.509 и Kerberos.

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

Первая спецификация SOAP была опубликована в 2000 г. Более ранняя версия, выпущенная в 1998 г., была известна как XML-RPC и имела более сфокусированный набор функций. Как и SOAP, XML-RPC позволяет выполнять удаленные вызовы процедур через XML. XML-RPC специально использует только HTTP для передачи данных. Хотя это общий протокол для SOAP, технически SOAP может использовать любой протокол.

Потребовалось три года, чтобы спецификация SOAP достигла стадии рекомендаций. Вскоре это стало наиболее распространенным подходом. к веб-сервисам. До SOAP не существовало основанного на стандартах подхода к созданию программируемых интерфейсов для обмен данными между системами. SOAP помогал внедрять инновации как внутри предприятия, так и поощрял первые волну общедоступных API от таких компаний, как eBay, Salesforce и Amazon.

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

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