Применение SOAP при интеграции систем
Применение SOAP при интеграции систем
Для начинающих аналитиков,
не имеющих опыта web-разработки
Смотреть запись вебинара
Историческая справка
В предыдущей статье мы говорили про то, что REST — это архитектурный стиль, который Рой Филдинг сформулировал в своей диссертации в 2000 году.
С протоколом SOAP дела обстоят несколько иначе.
SOAP — это не стиль, а протокол. Аббревиатура SOAP так и расшифровывается: Simple Object Access Protocol — простой протокол доступа к объектам. То есть правила передачи информации в SOAP строго стандартизированы, есть спецификация, которой нужно соответствовать.
SOAP появился 1998 году и был передан в организацию World Wide Web Consortium (W3C) — международная организация, которая курирует развитие интернета.
Почему разница в 2 года в появлении REST и SOAP так сказалась на их популярности?
Все просто — компания Microsoft активно вкладывала деньги в продвижении SOAP. На тот момент Microsoft активно продвигал свою новую платформу .NET (платформа, в которой все конфигурационные файлы представлены в формате XML, и используется протокол SOAP). Так вот, на рекламу этой платформы Microsoft потратил 200 млн долларов.
Если сравнить это с тем фактом, что Рой Филдинг просто представил REST в своей диссертации, то вы поймете, почему SOAP завоевал популярность очень быстро.
Тем не менее на данный момент можно говорить о том, что в основном для интеграции систем используется REST.
Жив ли еще SOAP?
Просмотрев статистику вакансий на сайте hh.ru, можно обнаружить, что примерно четверть вакансий аналитиков содержат требования к знанию SOAP, WSDL и, как следствие, XML. В основном это крупные компании, которые занимаются проектами более 10 лет (банки, телеком).
В чем разница между REST и SOAP?
Для того, чтобы наглядно показать отличие REST от SOAP, приведем вот такую аналогию. Представьте себе дерево, в котором есть дупло, и из этого дупла выглядывает птичка. Когда вы обращаетесь к какому-то приложению, вы как будто обращайтесь к такому дереву и стучитесь в окошко. Условно можно считать, что в это окошко выглядывает некоторая функция.
Если вы работаете с REST, то можно себе представить дерево, в котором есть много таких окошек — большое количество птичек, каждая из которых выглядывает из своего дупла. Это дупло называется Endpoint, но это отдельный разговор. Важно, что каждый раз, обращаясь к дуплу, вы обращаетесь только к одной функции.
SOAP основывается на технологии удаленного вызова процедур. Сервис, который работает на базе SOAP — это дерево с одним-единственным дуплом. Но каждый раз, обращаясь к этому дуплу, вы должны указать название процедуры, то есть название функции, которую вы хотите вызвать, потому что функций там может быть несколько. И, разумеется, вы должны передать те входные данные, которые нужны для процедуры, которую вы собираетесь вызвать.
Что из себя представляет SOAP
и когда его нужно использовать
Клиент-серверная архитектура приложения
В SOAP передача данных идет по протоколу HTTP, то есть также, как это происходит и в случает REST-запросов.
Давайте рассмотрим на примере. Если я зайду на сайт какой-нибудь биржи акций, то могу узнать курс интересующей меня акции. Откуда поступает эта информация? Давайте разберемся.
Клиент и сервер SOAP
Я открываю на своем компьютере браузер, который является клиентом. По протоколу HTTP он обращается к серверу (назовем его HTTP-server).
На этом HTTP-сервере живёт приложение, которое отдает мне информацию, о том, что акция Facebook стоит, к примеру, 252 доллара. Однако, откуда само приложение, живущее на HTTP-сервере, знает стоимость акции?
А все очень просто — приложение в данном случае выступило как SOAP-client и запросило эту информацию на другом сервере (назовем его SOAP-server).
Взаимодействие SOAP-client и SOAP-server происходит по протоколу SOAP поверх HTTP. Что значит поверх? Это значит, что клиент и сервер общаются по протоколу HTTP, но по этому протоколу передаётся не просто стандартное сообщение HTTP, а некий конвертик с письмом, причем это письмо написано по правилам протокола SOAP.
То есть сайт, который передал мне информацию о Facebook, сам запросил SOAP-server (то есть биржу акций) по протоколу HTTP и вложил сообщение в конвертик SOAP.
Таким образом, информация о курсе акции пришла ко мне не напрямую с биржи, а через посредника — через SOAP-client.
Курс Елены Бенкен
«Основы проектирования интеграций»
Курс для ИТ-аналитиков и проектировщиков, знакомых с техникой use cases (сценарии использования) и разработкой требований к качеству ПО,
которым необходимо разобраться в теме интеграций и
научиться проектировать взаимодействие ИТ-систем
Посмотреть программу курса |
Стек протоколов веб-сервисов
Давайте посмотрим на стек технологий, которые используются в данном случае:
Протоколы веб-сервисов
Когда мы работаем по сети, мы работаем с протоколами TCP/IP — это нижний, сетевой уровень протоколов. Весь интернет базируется на протоколе HTTP, который мы рассматривали в предыдущей статье. HTTP является просто транспортом, с помощью которого информация передается по сети.
Чтобы передать какое-либо сообщение по сети, оно должно соответствовать правилам протокола HTTP. А дальше в пакетик, передаваемый по протоколу HTTP, вкладывается сообщение по протоколу SOAP. И все это живет по правилам, описанным в файле WSDL.
Как выглядит xml-документ?
Представьте себе, что вы хотите передать по сети некоторую записочку. И вы хотите, чтобы информация в ней была структурирована так, чтобы записку могла прочитать программа.
В качестве примера приведу записку, которую Анна пишет Марии: «Приходи ко мне в гости в воскресенье!». И заголовок: «Напоминалка» (Reminder). Здесь могла бы быть ещё подпись signature, но, как видите, подпись оказалась пустой, информация в теге не передана (такое тоже возможно).
Тег — это текстовая строка, завернутая в уголочки (<>).
Пример XML-документа
То есть, когда мы передаем XML-документ, мы информацию «заворачиваем» в теги. Они предназначены для того, чтобы объяснять, что лежит внутри. Теги бывают открывающие (перед текстовым содержимым) и закрывающие (начинается с символа «/»).
В HTML такие же теги, но они применяются немного по-другому: в языке XML эти теги предназначены для того, чтобы объяснить приложению, которое принимает сообщение, что именно вложено внутрь.
Приложение, которое принимает записку, заранее знает, какие должны прийти данные внутри каких тегов. И знает оно это благодаря WSDL.
Что такое WSDL? В SOAP для описания своего сервиса нужно использовать строгие правила в виде файлов WSDL. Ниже мы разберем это подробнее, но вообще WSDL — это Web Services Description Language, ещё один язык описания веб-сервисов и доступа к ним.
Как устроен xml-документ?
Разберем приведенный ранее пример детальнее.
Первая строка документа — XML-декларация, она указывает на версию XML (version=»1.0″) и тип кодировки документа (encoding=»utf-8″).
XML-декларация всегда начинается с символов <?xml и заканчивается символами ?>.
Декларация должна располагаться в самом начале файла, то есть первым символом файла должна быть угловая скобка и никаких концов строки или пробелов.
Правильно оформленный XML соответствует правилам:
- Каждый открывающий тег должен иметь соответствующий закрывающий тег.
- Теги не могут перекрывать друг друга.
- XML- документы должны иметь только один корневой элемент.
- Регистр символов (верхний/нижний) для XML существенен.
Что ещё есть в xml-документе?
Всё XML-сообщение (наша записочка) заворачивается в так называемый корневой тег. В данном случае, корневым является тег note, который выделен зеленым.
Правильно оформленный XML это такой XML, который соответствует стандартам языка и может быть разобран приложением, то есть приложение его получит, проверит синтаксис и начнет разбирать.
Важно понимать, что приложение не будет разбирать XML если он не будет правильно оформлен. В этом случае приложение придёт к выводу, что XML повредили или подменили по дороге.
Если мы посмотрим на XML-документ внимательно, то сможем построить вот такое дерево:
Дерево XML-документа
То есть с точки зрения приложения XML представляет собой дерево, состоящее из узлов. Например на картинке вы можете видеть имена узлов: note, to, from, heading, body, signature.
Узлы вкладываются друг друга, и получается, что XML-документ можно представить в виде перевернутого дерева, только дерево растет вниз. Тeг note является корнем и в него вложены остальные теги, все они являются детьми этого корня. Кроме того, есть ещё текстовых узлы Мария, Анна и т. д.
Атрибуты элементов в XML
Теги могут содержать атрибуты, то есть мы можем вложить атрибуты в корневой тег. Посмотрите, информация о том, от кого записка (from) и кому (to) в приведенном ниже кусочке XML оформлена не как теги, а как атрибуты тега note.
Пример тега, содержащего атрибут
Смысл XML в том, что теги удобно обрабатывать, и вариант, когда вы вкладываете информацию в виде текстовых узлов внутри тегов, довольно устойчив к ошибкам.
Представьте себе, что по пути потеряется буква «r» в слове from. Если она потеряется только в одном месте, то посмотрев на первый тег, мы поймем, как должен называться второй, или во всяком случае мы поймём, где произошла ошибка.
Разговоры о том, что какая-то буква потерялась, не очень актуальны сейчас, так как современные протоколы обеспечивают целостную доставку. Данный пример призван продемонстрировать, что XML-документ в первую очередь создаётся для того, чтобы информацию вкладывать в теги.
Атрибуты — это пары имя/значение, поставленные в соответствие одному из элементов. Они должны находиться при открывающем теге, но не при закрывающем.
Атрибуты всегда должны иметь значение, даже если значением является всего лишь пустая строка. Значения атрибутов должны заключаться в кавычки. При этом согласно синтаксису XML допускаются как двойные, так и одинарные кавычки.
Если вам придется руками формировать XML-документ, никогда не пишите в одном документе и двойные и одинарные кавычки, просто потому что вам лень аккуратненько расставить однотипные, поскольку это может привести к ошибкам.
Пространства имён
Чтобы наглядно объяснить, что такое пространство имён, рассмотрим следующий пример.
Представьте себе, что по интернету ходят 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:
- Надёжность (за счёт отсутствия необходимости сохранять информацию о состоянии клиента, которая может быть утеряна).
- Производительность (за счёт использования кеша).
- Масштабируемость.
- Прозрачность взаимодействия между системами по сети.
- Простота интерфейсов.
- Портативность компонентов.
- Лёгкость внесения изменений.
- Способность эволюционировать, приспосабливаясь к новым требованиям.
Поясним несколько важных моментов. Если говорить о простоте интерфейсов, то разумеется 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>
, тоже могут иметь свои вложенные элементы. Грубо говоря, пространство
описывает объект индивидуума (вместе с <address>
и т.д., так как является старшим в иерархии), а вот <address>
внутри <person>
еще и группирует свое подпространство из <street>
, <city>
и <country>
. Т.е. если символически спросить адрес, то получим 3 значения из вложенных элементов (замечу, что это всего лишь символическое объяснение).
Так вот, передавая в SOAP именно такую структуру, мы можем сообщить некоему серверному сценарию не только переменные и их значения, но и их зависимость и иерархию.
<address>
— ведь серверному сценарию очень легко получить полный адрес из трех элементов, видя, что родительский (объединяющий) элемент <address>
имеет вложенные элементы! Как бы вы тогда сгруппировали бы эту структуру зависимости, используя обычный формат (как приведено в примере URL в самом начале)? Ок, в таком случае где-то в серверном сценарии должно быть указано, что некий адрес необходимо формировать из значений street, city и country — тоже выход, не спорю.А теперь усложним задачу: вам надо передать
<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, многие предпочитают более гибкий и быстрый процесс разработки.