С работа с soap: Как сделать клиента SOAP/WSDL в C#?

Отличия между SOAP и REST Web-сервисами

В каждой отрасли бизнеса, каждой компании, как правило, используется целый зоопарк ПО, например: сайт на 1С-Битрикс, CRM 1С-Битрикс24, учетная система на базе 1С. Одни системы “из коробки” умеют взаимодействовать с «соседними» продуктами, другие же приходится дорабатывать. За десятилетия существования веба как отрасли сформировались следующие практики межсетевого взаимодействия:

1. Обмен файлами по FTP.

2. Неструктурированные HTTP-запросы, договорённости между разработчиками.

3. Веб-сервисы.

4. Экзотика: сокеты, порты, бинарные объекты.

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

Что такое веб-сервисы?

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

Главное отличие веб-сервиса от других способов передачи данных: стандартизированность. Приняв решение использовать веб-сервисы, можно сразу переходить к структуре данных и доступным функциям. Например, В SOAP (как более строгом протоколе), уже решён вопрос уведомления об ошибках.

Самые известные способы реализации веб-сервисов:

• XML-RPC (XML Remote Procedure Call) — протокол удаленного вызова процедур с использованием XML. Прародитель SOAP. Предельно прост в реализации.

• SOAP (Simple Object Access Protocol) — стандартный протокол по версии W3C. Четко структурирован и задокументирован.

• JSON-RPC (JSON Remote Procedure Call) — более современный аналог XML-RPC. Основное отличие — данные передаются в формате JSON.

• REST (Representational State Transfer) — архитектурный стиль взаимодействия компьютерных систем в сети основанный на методах протокола HTTP.

• Специализированные протоколы для конкретного вида задач, такие как GraphQL.

• Менее распространенный, но более эффективный gRPC, передающий данные в бинарном виде и использующий HTTP/2 в качестве транспорта.

Остальные протоколы не так широко распространены. Подробно рассмотрены в статье будут SOAP и REST.

SOAP

SOAP (Simple Object Access Protocol) — Данные передаются в формате XML.

Преимущества:

• отраслевой стандарт по версии W3C;

• наличие строгой спецификации;

• широкая поддержка в продуктах Microsoft,

• однозначность.

Недостатки:

Любое сообщение в протоколе SOAP — это XML документ, состоящий из следующих элементов (тегов):

• Envelope. Корневой обязательный элемент. Определяет начало и окончание сообщения.

• Header. Необязательный элемент — заголовок. Содержит элементы, необходимые для обработки самого сообщения. Например, идентификатор сессии.

• Body. Основной элемент, содержит основную информацию сообщения. Обязательный.

• Fault. Элемент, содержащий информацию об ошибках, возникающих в процессе обработки сообщения. Необязательный.

Пример SOAP запроса:

Пример SOAP ответа:

REST

REST (Representational State Transfer) — на самом деле архитектурный стиль, а не протокол. В отличие от SOAP, REST не подкреплен официальным стандартом. Фактически, он основывается на соглашениях. Веб-сервис, построенный с учетом всех требований и ограничений архитектурного стиля, можно назвать RESTful веб-сервисом.

REST не использует конвертацию данных при передаче, данные передаются в исходном виде — это снижает нагрузку на клиент веб-сервиса, но увеличивает нагрузку на сеть. Управление данными происходит с помощью методов HTTP:

• GET — получить данные;

• POST — добавить данные;

• PUT — изменить данные;

• DELETE — удалить данные.

Использование этих методов позволяет реализовать типичный CRUD (Create/Read/Update/Delete) для любой информации. Но это лишь соглашение: часто используются только 2 метода: GET для получения и POST для всего остального. Разобраться поможет такое понятие, как REST-Patterns . Паттерны связывают HTTP методы с тем, что они делают.

Преимущества:

• простота реализации;

• экономичность в плане ресурсов;

• не требует программных надстроек (json_decode есть почти в каждом языке).

Недостатки:

Пример REST запроса:

Пример REST ответа:

Что же использовать?

Вопрос “Какой способ реализации использовать?” необходимо рассматривать в контексте реализуемой системы и ее ограничений. Обычно, SOAP используется в крупных корпоративных системах со сложной логикой, когда требуются четкие стандарты, подкрепленные временем. XML-RPC, пожалуй, устарел и не имеет смысла ввиду наличия собрата JSON-RPC. RPC-протоколы подойдут для совсем простых систем с малым количеством единиц информации и API-методов. 

Если же вы разрабатываете публичное API и логика взаимодействия во многом покрывается четверкой методов CRUD — смело выбирайте REST. Он наиболее популярен в WEB. Яндекс, Google и другие используют именно его для своего API.

Веб-сервисы в Битрикс

Подробное описание реализации веб-сервисов с помощью средств Битрикс можно найти в статье Веб-сервисы в Битриксе (пример) .

Веб-сервисы в живом производстве

Разработка веб-сервисов — типичная задача интеграции. ИНТЕРВОЛГА, как веб-интегратор, регулярно сталкивается с задачами разработки веб-сервисов и успешно с ними справляется. Наши сайты были и SOAP/REST серверами, и SOAP/REST клиентами. 

Успешным примером внедрения веб-сервисов является проект Enterprise-уровня — Личный кабинет клиентов компании Евраз Металл Инпром . Все функции личного кабинета основываются на взаимодействии с удаленным SOAP веб-сервисом. Сайт выступает клиентом. В процессе эволюции в угоду безопасности сайт переквалифицировался в SOAP-сервер, а учетная система в SOAP-клиента.  

Еще один личный кабинет для клиентов компании Евраз — еще один пример сайта в качестве клиента удаленного SOAP веб-сервиса.

Если у вас есть потребность организовать взаимодействие с веб-сервисом, сделать из сайта REST/SOAP/RPC клиент или сервер, обращайтесь к нам.

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

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

2. Можно провести аналогию с эволюцией разработки сайтов. Когда-то, на заре сайтостроения, каждый разработчик делал сайт с нуля на той технологии, которую мог знать лишь он один. Это порождало проблемы в развитии таких сайтов. Как работали такие сайты — знал только автор кода. Со временем появлялись фреймворки и CMS. Разработку начинали не с нуля, а с известных широкой массе разработчиков “заготовок” — стандартных решений стандартных проблем с возможность расширения и углубления.
   

   Также и с обменом данными. Не нужно тратить месяцы на объяснение новому сотруднику и самому себе, как работает обмен. Есть стандарт, обмен работает по нему.

Оцените статью:

Спасибо, ваш голос успешно добавлен!

• 09.07.2019
• Александр П.

ViPNet EDI Soap Gate 3 | Системы электронного документооборота

Программно-аппаратный комплекс ViPNet EDI Soap Gate 3 предназначен для осуществления обмена электронными сведениями между участниками межведомственного взаимодействия по каналам СМЭВ с применением электронной подписи.

---

Сценарии использования

ViPNet EDI Soap Gate 3 позволяет формировать различные сценарии создания информационной системы ведомства, организации для работы с СМЭВ.

Возможны следующие сценарии работы:

1. Работа с запросами и ответами с помощью программного обеспечения ViPNet EDI Client G2G 3, установленного на рабочих местах пользователей. При этом прием и отправка запросов в СМЭВ производится с использованием ViPNet EDI Soap Gate 3.
2. Генерация запросов и ответов осуществляется с помощью собственной информационной системы Заказчика. Прием и отправка запросов в СМЭВ производится с использованием ViPNet EDI Soap Gate 3.
3. Комбинация указанных сценариев использования.

Преимущества

1. Одновременная поддержка криптографических алгоритмов ГОСТ Р 34.10-2001 и ГОСТ Р. 34.11-94, а также ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012.
2. Обеспечение одновременной работы с СМЭВ 2.xх и СМЭВ 3.xх.
3. Встроенные возможности интеграции с государственными информационными системами: ЕПГУ, ЕСИА, ГИС ГМП 2.0, ГАСУ, ФГИС ДО, ГЭПС и пр.
4. Возможность разграничения служебной и пользовательской информации.

---

Сертификация в ФСБ России

ПАК ViPNet EDI Soap Gate 3 соответствует требованиям к средствам криптографической защиты информации класса КС3 и требованиям к средствам электронной подписи для класса КС3 (СФ/124-3677 от 12.04.2019).

Гарантийное обслуживание

1 год

Техническая поддержка

1 год

---

ИнфоТеКС оставляет за собой право без уведомления вносить изменения в поставляемую продукцию (характеристики, внешний вид, комплектность), не ухудшающие ее потребительских свойств.

---

Функциональные характеристики

• Подписание электронной подписью организации (ЭП-ОВ) исходящих запросов/ответов, проверка электронных подписей входящих запросов/ответов.
• Маршрутизация входящих запросов СМЭВ между подразделениями Заказчика в зависимости от настраиваемых правил маршрутизации.
• Хранение запросов /ответов и их истории.
• Мониторинг запросов.
• Мониторинг работоспособности сервера системы.
• Регистрация и аутентификация пользователей ViPNet EDI Client G2G 3.
• Обеспечение синхронных и асинхронных методов взаимодействия с сервисами: ФНС, МВД, Росреестр, ПФР, Казначейства, ФОМС, ФССП и пр.
• Использование способов передачи вложений через СМЭВ 3.хх с использованием механизма МТОМ и с использованием Файлового хранилища.
• Возможность отправлять и подписывать ЭП-ОВ сведений в режиме «Рассылка».

Дополнительные возможности

Сертификаты

Сертификаты ФСБ России

Сертификат соответствия ФСБ России № СФ/124-3677 от 12.04.2019 на соответствие программно-аппаратного комплекса ViPNet EDI Soap Gate 3 (ViPNet ЭДО Шлюз безопасности 3) требованиям ГОСТ P 34.10-2012, ГОСТ P 34.11-2012. Требованиям к средствам криптографической защиты информации класса КС3. Требованиям к средствам электронной подписи для класса КС3.

Срок действия:

Свидетельства

Дата регистрации:

Настроить интеграцию с веб-сервисом SOAP

Возможность настройки интеграции с веб-сервисом SOAP доступна для приложений Creatio версии 7.17.2 и выше.

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

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

Этапы настройки интеграции с веб-сервисом:

1. Добавление веб-сервиса и настройка его свойств и методов.
2. Настройка аутентификации веб-сервиса (опциональный шаг). Настройка аутентификации идентична для REST и SOAP-сервисов.
3. Проверка интеграции с веб-сервисом.

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

Пример. Настроить интеграцию с SOAP-сервисом “PhoneVerify” (https://ws.cdyne.com/phoneverify/phoneverify.asmx) для получения информации по номеру телефона.

Необходимо реализовать поддержку следующих параметров:

• “CheckPhoneNumber” — метод, который возвращает информацию по номеру телефона.
• “PhoneNumber” — параметр запроса, в который необходимо передать номер телефона. Обязательный параметр.
• “LicenseKey” — параметр запроса, в который необходимо передать ключ.
• “Company” — параметр ответа, который содержит название компании.
• “Valid” — параметр ответа, который содержит информацию о корректности полученной информации.

Creatio позволяет импортировать wsdl-файл или настроить интеграцию вручную.

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

Автоматическая настройка свойств и методов веб-сервиса 

1. Перейдите в рабочее место Студия и откройте раздел Веб-сервисы.
2. Нажмите Добавить веб-сервис —> SOAP сервис.
3. В окне “Быстрая настройка SOAP веб-сервиса” нажмите Выбрать файл или добавьте ссылку на wsdl-файл с описанием веб-сервиса, интеграцию с которым необходимо настроить.
4. В окне “Настройка SOAP веб-сервиса” выберите, какой сервис и версию SOAP использовать. Также настройте методы, которые необходимо вызывать, и параметры вызова методов. Нажмите Далее.
5. В окне “Настройка SOAP веб-сервиса” выберите необходимые параметры ответов методов. Нажмите Сохранить (Рис. 1).

Настройка веб-сервиса выполнена. Все свойства и методы на странице сервиса будут заполнены автоматически. Далее переходите к проверке интеграции с SOAP-сервисом.

Ниже приведен альтернативный способ настройки свойств и методов веб-сервиса.

Ручная настройка свойств и методов веб-сервиса 

1. Перейдите в рабочее место Студия и откройте раздел Веб-сервисы.
2. Нажмите Добавить веб-сервис —> SOAP сервис.
3. В окне “Быстрая настройка SOAP веб-сервиса” нажмите Пропустить быструю настройку.
4. Изучите документацию веб-сервиса. В нашем примере используется следующий код.
5. Заполните поля страницы свойств веб-сервиса (Рис. 2).

   Поле	Комментарий	Пример
   Название	Название будет отображаться в поле Какой сервис вызывать? области свойств элемента процесса Вызвать веб-сервис.	Сервис получения информации по телефонному номеру
   Код	Используется разработчиками для взаимодействия с веб-сервисом в программном коде Creatio. В данном случае уникальное имя интеграции с веб-сервисом состоит из его названия и префикса “Usr”.	UsrPhoneVerifyService
   Пространства имен	Необходимо указывать только пространства имен, которые используются для методов и их параметров. Набор пространств имен задается в формате “Префикс пространства имен”:“Пространство имен”, разделенных символом “;” или переводом строки. Если пространство имен только одно, то его можно задать без префикса. Это пространство имен будет применено ко всему запросу.	http://ws.cdyne.com/PhoneVerify/query
   URI сервиса	Полный адрес вызова веб-сервиса будет состоять из этого URI и настроек, указанных на странице настройки метода. Используйте такой же протокол (http/https), как и у сайта вашего приложения Creatio. Если веб-сервис содержится в недоступном для редактирования пакете, то его URI будет доступен для редактирования.	http://ws.cdyne.com/phoneverify/phoneverify.asmx?WSDL
   Повторов вызова при ошибках	Если ответ от веб-сервиса пришел с кодом ошибки или истек тайм-аут ответа, то запрос будет повторен указанное количество раз. При заполнении этого поля учитывайте тайм-аут ответа, который будет указан для методов веб-сервиса.	По умолчанию — 0
   Пакет	Пакет, в котором будет сохранена данная интеграция с веб-сервисом. В списке отображаются пакеты, которые доступны для изменения текущим пользователем.	SoapWebServicePackage

На заметку. Интеграции с веб-сервисами сохраняются в виде элементов конфигурации. Если такой элемент конфигурации находится в пакете, который недоступен для редактирования, то вы сможете изменить только URI веб-сервиса. Для внесения других изменений (например, для добавления методов) в такие интеграции с веб-сервисами скопируйте соответствующие элементы конфигурации в доступный для редактирования пакет.

Настроить вызов метода 

Для каждого веб-сервиса необходимо настроить вызов методов. При этом для одного веб-сервиса можно настроить несколько методов.

1. На детали Методы страницы настройки интеграции с веб-сервисом при помощи кнопки добавьте методы.
2. Изучите документацию веб-сервиса. В нашем примере используется следующий код.
3. Заполните свойства метода (Рис. 3).

   Поле	Комментарий	Пример
   Название	Название будет отображаться в поле Какой сервис вызывать? области свойств элемента процесса Вызвать веб-сервис.	Проверить номер телефона
   Код (на английском)	Используется разработчиками для взаимодействия с веб-сервисом в программном коде Creatio. В данном случае уникальное имя интеграции с веб-сервисом состоит из его названия и префикса “Usr”.	UsrCheckPhoneNumber
   Код элемента сообщения	Название узла XML, который является корневым внутри <soap:Body>. Часто совпадает с названием операции в WSDL. Например, это будет “MessageElementName” в следующем теле запроса:	CheckPhoneNumber
   SOAP Action	Для определения данного значения используется документация веб-сервиса. Например, у веб-сервиса “PhoneVerify” есть “конечная точка” “CheckPhoneNumber”, которая возвращает информацию по номеру телефона.	http://ws.cdyne.com/PhoneVerify/query/CheckPhoneNumber
   Тайм-аут ответа, мс	Время ожидания ответа от веб-сервиса. Если после отправки запроса не был получен ответ, либо был получен код ошибки, то по истечении этого времени Creatio повторит запрос (если еще остались неиспользованные попытки повторного вызова).	По умолчанию — 5 000
   Использовать аутентификацию	Использовать аутентификацию для доступа к веб-сервису. Необходимо настроить аутентификацию на детали Аутентификация страницы настройки интеграции с веб-сервисом. Подробнее: Аутентификация веб-сервиса.	По умолчанию — false

Настроить параметры запроса 

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

Количество и типы параметров запроса определяются спецификой веб-сервиса. Параметры необходимо добавлять относительно метода.

Доступны следующие типы параметров запроса:

Параметр тела	Этот тип параметра используется для отправки любых типов данных (включая коллекции) в теле запроса. Подробнее о методе POST запроса читайте в Википедии.
Параметр заголовка	Этот тип параметра используется для генерации заголовка запроса. Подробнее об HTTP-заголовках читайте в Википедии.
Параметр cookies	Параметры этого типа используются для передачи файлов cookie в запросах к сервису. Например, можно передать полученный ранее cookie для аутентификации. Подробнее о cookie читайте в Википедии.

Для настройки параметров запроса:

1. Изучите документацию веб-сервиса. В нашем примере используется следующий код.
2. Добавьте параметры запроса:
   1. На вкладке Параметры вызова нажмите кнопку Добавить параметр.
   2. Добавьте параметр “Номер телефона” и заполните его свойства (Рис. 4).

      Поле	Комментарий	Пример
      Название	Название параметра сервиса.	Номер телефона
      Тип параметра	Тип параметра сервиса.	Параметр тела
      Путь к элементу	Если для параметра используется пространство имен, то оно указывается в формате “Префикс пространства имен”:“Путь к параметру”.	PhoneNumber
      Код в Creatio	Используется разработчиками для взаимодействия с веб-сервисом в программном коде Creatio. В данном случае уникальное имя интеграции с веб-сервисом состоит из его названия и префикса “Usr”.	UsrPhoneNumber
      Тип данных	Тип данных параметров сервиса. Параметр с вложенными элементами должен иметь тип данных “Объект”.	Текст
      Является массивом	Значение параметра-массива нельзя задать в элементе “Вызвать веб-сервис” в дизайнере процессов. Необходимо использовать элемент “Задание-сценарий”. Параметр с типом данных “Объект” обязательно должен быть массивом.	По умолчанию признак снят
      Обязательный	При установленном признаке параметр будет обязательным в дизайнере процессов. Признак недоступен для редактирования при выборе значения по умолчанию.	По умолчанию признак установлен
      Значение по умолчанию	Значение параметра по умолчанию.	Константа

   3. Добавьте параметр “Ключ” и заполните его свойства (Рис. 5).

      Поле	Комментарий	Пример
      Название	Название параметра сервиса.	Ключ
      Тип параметра	Тип параметра сервиса.	Параметр тела
      Путь к элементу	Если для параметра используется пространство имен, то оно указывается в формате “Префикс пространства имен”:“Путь к параметру”.	LicenseKey
      Код в Creatio	Используется разработчиками для взаимодействия с веб-сервисом в программном коде Creatio. В данном случае уникальное имя интеграции с веб-сервисом состоит из его названия и префикса “Usr”.	UsrLicenseKey
      Тип данных	Тип данных параметров сервиса. Параметр с вложенными элементами должен иметь тип данных “Объект”.	Текст
      Является массивом	Значение параметра-массива нельзя задать в элементе “Вызвать веб-сервис” в дизайнере процессов. Необходимо использовать элемент “Задание-сценарий”. Параметр с типом данных “Объект” обязательно должен быть массивом.	По умолчанию признак снят
      Обязательный	При установленном признаке параметр будет обязательным в дизайнере процессов. Признак недоступен для редактирования при выборе значения по умолчанию.	По умолчанию признак установлен
      Значение по умолчанию	Значение параметра по умолчанию.	Константа

Настроить параметры ответа 

Для настройки параметров ответа:

1. Изучите документацию веб-сервиса. В нашем примере используется следующий код.
2. Добавьте параметры обработки ответа:
   1. На вкладке Обработка ответа нажмите кнопку Добавить параметр.
   2. Добавьте параметр “Компания” и заполните его свойства (Рис. 6).

      Поле	Комментарий	Пример
      Название	Название параметра сервиса.	Компания
      Тип параметра	Тип параметра сервиса.	Параметр тела
      Путь к элементу	Если для параметра используется пространство имен, то оно указывается в формате “Префикс пространства имен”:“Путь к параметру”.	CheckPhoneNumberResponse/CheckPhoneNumberResult/Company
      Код в Creatio	Используется разработчиками для взаимодействия с веб-сервисом в программном коде Creatio. В данном случае уникальное имя интеграции с веб-сервисом состоит из его названия и префикса “Usr”.	UsrCompany
      Тип данных	Тип данных параметров сервиса. Параметр с вложенными элементами должен иметь тип данных “Объект”.	Текст
      Является массивом	Значение параметра-массива нельзя задать в элементе “Вызвать веб-сервис” в дизайнере процессов. Необходимо использовать элемент “Задание-сценарий”. Параметр с типом данных “Объект” обязательно должен быть массивом.	По умолчанию признак снят
      Значение по умолчанию	Значение параметра по умолчанию.	Константа

   3. Добавьте параметр “Валидно” и заполните его свойства (Рис. 7).

      Поле	Комментарий	Пример
      Название	Название параметра сервиса.	Валидно
      Тип параметра	Тип параметра сервиса.	Параметр тела
      Путь к элементу	Если для параметра используется пространство имен, то оно указывается в формате “Префикс пространства имен”:“Путь к параметру”.	CheckPhoneNumberResponse/CheckPhoneNumberResult/Valid
      Код в Creatio	Используется разработчиками для взаимодействия с веб-сервисом в программном коде Creatio. В данном случае уникальное имя интеграции с веб-сервисом состоит из его названия и префикса “Usr”.	UsrValid
      Тип данных	Тип данных параметров сервиса. Параметр с вложенными элементами должен иметь тип данных “Объект”.	Логическое
      Является массивом	Значение параметра-массива нельзя задать в элементе “Вызвать веб-сервис” в дизайнере процессов. Необходимо использовать элемент “Задание-сценарий”. Параметр с типом данных “Объект” обязательно должен быть массивом.	По умолчанию признак снят
      Значение по умолчанию	Значение параметра по умолчанию.	Константа

Нажмите кнопку Сохранить для сохранения настроек.

Настроить параметры запроса и ответа типа “коллекция” 

Коллекцией (или массивом) является набор элементов. Creatio может передавать коллекции данных в веб-сервис и обрабатывать его ответы, содержащие коллекции. Если веб-сервис поддерживает получение и/или отправку массивов данных, то параметры типа “коллекция” можно использовать как для вызова веб-сервиса, так и для обработки его ответа.

Типы параметров коллекции:

• Простая коллекция. Любой параметр можно представить в виде коллекции, установив в свойствах параметров признак “Является массивом”. Простые коллекции являются массивами значений одного типа данных. Каждое значение является отдельным элементом коллекции. Например, “1, 2, 3” — это простой массив значений целых чисел, а “Бостон, Нью Йорк, Чикаго” — простой массив текстовых значений.
• Коллекция объекта. Коллекция представляет собой корневой параметр (т. н. объект), который содержит вложенные параметры.

Для настройки коллекции:

1. Изучите документацию веб-сервиса. В нашем примере используется следующий код.
2. Добавьте метод “CheckPhoneNumbers”. Поля методов описаны на шаге Настроить вызов метода.

3. Настройте параметры запроса. Поля параметров описаны на шаге Настроить параметры запроса.

   Обратите внимание, что в соответствии с документацией веб-сервиса параметр запроса “ArrayOfString” — комплексный тип, который состоит из массива элементов “string”. Для настройки параметров запроса, который является коллекцией:

   1. В поле Тип параметра выберите “Параметр тела”.
   2. Установите признак Является массивом.
   3. В поле Название элемента массива укажите “string” (Рис. 8). По умолчанию — “item” (для простых массивов).
4. Изучите документацию веб-сервиса. В нашем примере используется следующий код.

5. Настройте параметры ответа. Поля методов описаны на шаге Настроить параметры ответа.

   В поле Тип данных выберите “Объект”. После этого станут доступны вложенные параметры (Рис. 9).

Параметры ответа веб-сервиса типа “коллекция” могут использоваться в качестве входящих параметров элемента бизнес-процесса Вызвать веб-сервис. Подробнее: Элемент процесса Вызвать веб-сервис.

Проверка интеграции с SOAP-сервисом 

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

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

Для проверки интеграции:

1. Откройте дизайнер процессов и создайте процесс с двумя последовательно выполняющимися элементами: Вызвать веб-сервис и Преднастроенная страница (Рис. 10).
2. Настройте свойства элемента Вызвать веб-сервис, как показано на Рис. 11.

   Поле	Комментарий	Пример
   Какой сервис вызывать?	Выберите веб-сервис, который необходимо вызвать.	Сервис получения информации по телефонному номеру
   Какой метод вызывать?	Выберите метод веб-сервиса, который необходимо вызвать.	Проверить номер телефона
   Параметры вызова	Параметры веб-сервиса, с которыми необходимо вызвать веб-сервис. Заполняется автоматически после выбора метода. В поле введите значение параметров, которые будут использованы при вызове веб-сервиса.	+1 617 765 7997

3. В области свойств преднастроенной страницы при помощи кнопки создайте новую преднастроенную страницу. В дизайнере преднастроенной страницы добавьте поля. В нашем примере это текстовые поля “Компания” и “Информация по телефонному номеру”, логическое поле “Валидно” (Рис. 12).

   Сохраните страницу.

4. В дизайнере процессов, в области свойств преднастроенной страницы настройте передачу значений параметров из элемента Вызвать веб-сервис в поля преднастроенной страницы, которые вы добавили (Рис. 13).
5. Сохраните бизнес-процесс.

   В результате при запуске процесса откроется преднастроенная страница (Рис. 14), поля которой будут заполнены значениями, полученными в ответе веб-сервиса.

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

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

SOAP взаимодействие

Взаимодействие с веб-сервисом расширения «Бром» происходит по стандартизированному протоколу SOAP. Данный протокол позволяет совершать удаленный вызов функций с передачей праметров и получением результата вызова. Для передачи данных в прямом и обратном направлении используются XML-сообщения определенной заранее описанной структуры. Отправка сообщений происходит по HTTP протоколу.

Ниже представлен пример XML-сообщений запроса и ответа:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:brom="https://brom.itworks.group">
   <soap:Header/>
   <soap:Body>
      <brom:GetObjectList>
         <brom:type>Перечисление</brom:type>
         <brom:name>СтавкиНДС</brom:name>
         <brom:settings />
      </brom:GetObjectList>
   </soap:Body>
</soap:Envelope>

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
   <soap:Body>
      <m:GetObjectListResponse xmlns:m="https://brom.itworks.group">
         <m:return xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <m:Item xsi:type="m:ValueEnumRef" Value="НДС0" Presentation="0%" Type="Перечисление.СтавкиНДС"/>
            <m:Item xsi:type="m:ValueEnumRef" Value="НДС10" Presentation="10%" Type="Перечисление.СтавкиНДС"/>
            <m:Item xsi:type="m:ValueEnumRef" Value="НДС18_118" Presentation="18/118" Type="Перечисление.СтавкиНДС"/>
            <m:Item xsi:type="m:ValueEnumRef" Value="БезНДС" Presentation="Без НДС" Type="Перечисление.СтавкиНДС"/>
            <m:Item xsi:type="m:ValueEnumRef" Value="НДС18" Presentation="18%" Type="Перечисление.СтавкиНДС"/>
            <m:Item xsi:type="m:ValueEnumRef" Value="НДС10_110" Presentation="10/110" Type="Перечисление.СтавкиНДС"/>
         </m:return>
      </m:GetObjectListResponse>
   </soap:Body>
</soap:Envelope>

Чем хорош SOAP?

SOAP протокол обладает рядом преимуществ, а именно:

Стандартизированный протокол

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

Структура данных описывается в XML

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

Строгая типизация данных

Типы данных (типы объектов) передваемые между удаленными приложениями строго описаны в XML-схеме, которая является частью WSDL-файла (описания сервиса). Даже если разработчик не знаком с правилами описания XML-схемы, программный компонент самомстоятельно может сформировать правильный XML-код, а также проверить его корректность.

Объектное взаимодействие

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

Повсеместная распространенность

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

SOAP сервисы поддерживают описание в WSDL

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

Как передаются данные?

В расширении «Бром» реализованы собственные механизмы сериализации данных. Благодаря этому в обоих направлениях возможна передача как данных примитивных типов (строки, числа, даты и пр..), так и сложных структурированных данных (массивы, таблицы, деревья, ссылки и пр..).

В XML-схеме сервиса описаны типы данных, которые соответствую встроенным типам данных 1С:Предприятие. Все типы данных XML-схемы, предназначеные для двусторонней передачи, являются производными от абстрактоного типа «brom:ValueBase». Полный список сериализуемых типов представлен в разделе «Сериализуемые типы данных».

Обозначения

Далее в документации для обозначения типов данных из разных пространств имен испольуется сокращенная запись. Пространства имен указываются в соответвии с правилами обозначения XML-схемы в виде префиксов. Для пространств имен использованы следующие обозначения:

xs = «http://www.w3.org/2001/XMLSchema» (пространство имен базовых типов)
brom = «https://brom.itworks.group» (пространство имен сервиса «Бром»)

Например, запись «brom:ValueArray» означает тип данных «ValueArray» из пространства имен «https://brom.itworks.group».

RTM: SoapUI для чайников — Первый Онлайн ИНститут Тестировщиков

Данная статья написана в помощь студентам ПОИНТ, которые проходят вебинар “Тестирование веб-сервисов”, и является, в первую очередь, практическим руководством по основам работы с программой SoapUI.

Вступление и пара слов о теории

Сегодня нужно хорошо постараться, чтобы найти софт, который никак не взаимодействует с другими программами. Обычно либо происходит равноценный обмен данными, либо стороннее ПО выполняет какие-либо вспомогательные функции, например, вычисления. И это совершенно нормально, при наличии тысяч готовых решений невыгодно или невозможно создавать все с нуля. Поэтому, то, что для конечного пользователя может выглядеть как единая программа или система, на самом деле чаще всего является набором самостоятельных сервисов. Этим сервисам нужно как-то между собой взаимодействовать (интегрироваться). И, как для общения программ с человеком существует пользовательский интерфейс UI, так и для взаимодействия программ между собой существует специальный интерфейс API (Application Programming Interface – интерфейс программирования приложений).

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

В данной статье речь пойдет об инструменте для функционального тестирования веб-сервисов — или, простыми словами, о специальных программах-помощниках. Они помогают сайтам и веб-приложениям общаться между собой в сети Интернет и передавать данные через специальный протокол HTTP(S). Веб-сервисы основываются на открытых протоколах и следуют общепринятым стандартам. Именно поэтому у приложений есть возможность общаться между собой вне зависимости от использованных при их создании технологий или пользовательского окружения. Для взаимодействия веб-приложений в основном используется два типа интерфейсов: REST API и SOAP API. Их различия и области типичного применения являются темой для отдельных статей.

Для тестирования API веб-приложений существует множество возможностей: начиная от написания своих собственных скриптов, работы в консоли и заканчивая специальными фреймворками, у которых доступен UI через обычный браузер (Swagger, Django REST framework и т.п.).  SoapUI — это один из многих инструментов для такого тестирования. Он поддерживает множество дополнительных возможностей, которые в самом начале могут не понадобиться, но именно поэтому может показаться новичкам излишне сложным. Однако, очевидным плюсом для новичков является то, что SoapUI предлагает поддержку REST и SOAP API, поэтому можно не осваивать отдельную программу для каждого типа веб-API.

Первый REST проект

Если веб-приложение использует REST API, то форматы документации могут сильно отличаться, а схема (WADL) опциональна. Единственное, без чего при тестировании REST не обойтись, так это без информации об endpoint, т.е. конечного адреса, куда отправляются запросы сервиса, инициирующего взаимодействие. Или, с другой стороны, точки входа для программы, с которой это взаимодействие осуществляется. Конечная точка сама по себе является просто ссылкой на URL, который принимает веб-запросы, которые в свою очередь могут быть или не быть REST. В зависимости от конкретной проверки этот адрес уточняется или к нему добавляются дополнительные параметры. Уточнения адреса являются уже детализированными ссылками на ресурсы, т.е. кусочки программы, которые непосредственно содержат данные, информацию о связях с другими кусочками программы, реализованные методы для взаимодействия и т.п. Иногда понятия ресурс и эндпоинт употребляются как синонимы.

Итак, приступим. В качестве подопытного будет выступать API спеллчекера от Яндекс https://tech.yandex.ru/speller/doc/dg/concepts/api-overview-docpage/ документация.

1. Создаем через меню File новый REST проект. Или в Navigator через меню, которое открывается по клику правой кнопкой мыши по Projects.

2. В открывшемся диалоговом окне вводим наш базовый URL, куда будут уходить все запросы: https://speller.yandex.net и нажимаем OK. Можно ввести и всю ссылку целиком, умный SoapUI сам разделит эндпоинт и ресурс.

3. После того, как проект создался, в рабочей области откроется окно с самим запросом. Здесь выбираем метод (в нашем случае по документации GET) и уточняем URL, дописываем ресурс, к которому обращаемся. У спеллчекера реализовано два ресурса checkText и checkTexts. Пока добавим первый.

4. Теперь можно смело добавить все возможные параметры для этого метода, они перечислены в документации. При этом значения можно оставлять пустыми, получится шаблон для тестов.

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

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

7. Добавляем в новый тест-кейс сам запрос. На данном этапе можно переименовать запрос. Но это переименование будет касаться только тест-кейса.

8. Ура, первый тест-кейс почти готов! Обратите внимание, что в самом тест-кейсе уже нельзя редактировать эндпоинт или ресурсы. Зато можно добавить значения параметрам и поменять запрос, который используется, если их несколько.

9. Самое время проверить, что сервис работает и ответ на запрос приходит. Заполняем параметр text словом с ошибкой и нажимаем на кнопку Play (зеленый треугольник). Видно, что параметр автоматически добавился в URL.

10. А теперь можно добавить второй ресурс /services/spellservice/checkTexts к уже существующему эндпоинту. Кликаем правой кнопкой мыши по нему и выбираем в контекстном меню New Resource. Так как эти ресурсы равноценны, то нужно его добавлять имено к эндпоинту, а не как дочерний ресурс к добавленному выше checkText.

11. Здесь все то же самое, выбираем метод, добавляем возможные параметры.

12. Чтобы поделиться REST проектом, его можно экспортировать как xml и тогда любой другой тестировщик сможет добавить этот файл в свой SoapUI и воспользоваться готовыми тест-кейсами. Для этого нажимаем правой кнопкой мыши на саму папку проекта и выбираем Save Project или Save Project as.  Если выбрать пункт Export Project, то xml файл проекта будет добавлен в zip-архив. Тоже самое можно сделать через главное меню в разделе Project.

Выше приведены самые базовые действия для создания тест-кейсов по REST сервису в SoapUI. На самом деле возможности инструмента, конечно, гораздо шире. Обо всем этом можно узнать на официальном сайте https://www.soapui.org/

Тестирование параметров происходит также, как на UI тестирование полей в форме, все базовые техники применимы и тут. Особенностью тестирования REST является возможность смотреть не только значения параметров, но и проверить, как тестируемая система реагирует на запросы к несуществующим ресурсам, с несуществующими параметрами, неверным методом. Если углубляться в данный вид тестирования, то можно проверять также заголовки запроса и форматы запросов/ответов.

Первый Soap проект

Если используется Soap API, то можно быть спокойным, у вас будет файл схемы. Тут уже все происходит автоматически, SoapUI создает проект на основе схемы и можно сразу увидеть все доступные запросы.

Продолжим с Яндексом. По данной ссылке https://speller.yandex.net/services/spellservice?WSDL  доступен WSDL файл, который нужно сохранить в формате xml.

1. Снова открываем меню File и создаем уже новый Soap проект.

2. В открывшемся диалоговом окне нужно назвать свой проект и загрузить скачанный ранее файл со схемой. Остальные галочки можно оставить по умолчанию.

3. Готово, проект создан, есть примеры запросов.

4. Теперь вместо “?” можно добавить значения в xml и отправить первый запрос.

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

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

На этом у меня все!

P.S.: По теории и более подробном тестировании REST и SOAP можно почитать следующие статьи:

https://quality-lab.ru/soap-api-testing/

https://quality-lab.ru/rest-api-testing/

Радченко Глеб Игоревич



Научные интересы

• Грид-вычисления.
• Облачные вычисления.
• Распределенные вычислительные системы.

Публикации

Проекты

1. Проект Erasmus+ PWs@PhD. Основная цель проекта PWs@PhD – поддержка развития, модернизации, интернационализации высшего образования, а именно исследовательской составляющей европейского образования уровня PhD, содействие созданию новых PhD-программ в странах-партнерах в области программной инженерии.
2. Сервисно-ориентированный подход к использованию проблемно-ориентированных пакетов в распределенных и грид-средах (проект DiVTB).
3. Параллельная реализация нейросетевого алгоритма распознавания раздельной речи (Часть 1, Часть 2, Часть 3).

Новости

• [2013-12-25]  Обновления страниц курсов:

• [2013-12-17]  Обновления страниц курсов:

• [2013-11-28]  Обновления страниц курсов:

 

• [2013-11-07]  Размещены слайды презентаций:

• [2013-10-26] Размещены слайды презентаций:

• [2013-06-03]  Размещены слайды презентаций:

[Архив новостей]

Ссылки

• Mendeley — система для каталогизации и управления библиографией. Встраивается в Microsoft Word, позволяя автоматизировать процесс управления списками литературы при подготовке статей. Поддерживает множество форматов оформления библиографических ссылок, включая ГОСТ-7.0.5-2008.
• Memsource — операционная среда для выполнения письменных переводов, включающая базы памяти переводов, встроенный машинный перевод, модуль управления терминологией, а также текстовый редактор MemSource Editor. Может импортировать и экспортировать документы всех стандартных форматов, включая Word и PowerPoint.

Мой профиль

 

Новый электронный курс «Работа с веб‑сервисами в Loginom»

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

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

Для аналитика важной является возможность быстрого получения данных от веб-сервиса для последующего анализа, а для решения ряда задач требуется создавать и публиковать собственные сервисы — всё это будет продемонстрировано в курсе «Работа с веб-сервисами в Loginom».

5 лекций и 6 практических занятий

• Работа с веб-сервисами в Loginom

       5 лекций, самопроверочный тренажер

• Создание веб-сервиса в Loginom

       6 практических занятий, самопроверочный тренажер.

Лекционные материалы

В этом разделе слушатель получит общие сведения о веб-сервисах: типах, архитектуре, веб-стандартах.

В лекционных материалах приведена история развития веб-сервисов и подробно рассмотрены базовые технологии: в чем разница между XML и JSON, какие преимущества и недостатки имеют реализации веб-сервисов на базе SOAP/WSDL и REST.

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

Содержимое лекций

Практические занятия

В первом занятии слушатель узнает о возможностях вызова веб-сервисов в Loginom и познакомится с компонентом платформы для публикации собственных сервисов Loginom Integrator.

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

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

Содержимое практических занятий

Более подробную информацию можно найти на странице курса, а стоимость доступа к Loginom e-Learning и список доступных курсов для индивидуальных слушателей или юридических лиц представлены в разделе «Обучение».

Начало работы с тестированием SOAP и WSDL в SoapUI

SoapUI поддерживает тестирование служб на основе WSDL / SOAP. Для расширенной функциональности попробуйте ReadyAPI бесплатно.

• Простой импорт WSDL и создание запросов по умолчанию для специального тестирования и изучения сервисов
• Поддержка часто используемых стандартов, таких как WS-Security, WS-Addressing, WS-ReliableMessaging, MTOM и т. Д., Позволяет тестировать расширенные службы и сценарии
• Интегрированные инструменты тестирования совместимости WS-I позволяют проверять как ваши контракты, так и сообщения на соответствие отраслевым стандартам
• Шаг теста SOAP-запроса позволяет проводить обширное функциональное тестирование и проверку сервисов с помощью различных возможностей утверждения и создания сценариев.
• Нагрузочное тестирование служб SOAP / WSDL поддерживается как естественное расширение функциональных тестов SoapUI
• Сервисные симуляции («MockServices») могут быть мгновенно созданы из вашего WSDL и запущены внутри SoapUI для имитации как простого, так и сложного поведения клиента
• Предоставляется графический интерфейс для генерации кода с помощью самых популярных сред разработки веб-сервисов, позволяющий легко сравнивать инфраструктуры и их артефакты.
• Все функциональные тесты, нагрузочные тесты и MockServices можно легко запустить как из SoapUI, так и с помощью встроенных инструментов командной строки.
Функциональность
• WSDL Coverage дает вам уникальное представление о покрытии ваших тестов по отношению к протестированным контрактам; вы проверили все элементы? Атрибуты? И т.д …
• Рефакторинг WSDL позволяет автоматически обновлять ваши тесты и симуляции, чтобы они соответствовали новым версиям ваших WSDL.
• Расширенные редакторы и мастера в ReadyAPI упрощают тестирование и изучение сервисов для нетехнических пользователей и тестировщиков.

Начало работы

Приступить к проведению специального тестирования службы SOAP несложно; выберите опцию «New Project» в меню File, после чего появится следующий диалог:

Вставьте путь WSDL http: // www.dneonline.com/calculator.asmx?wsdl в поле Initial WSDL / WADL (из него будет извлечено имя проекта) и нажмите OK. SoapUI немного поработает и создаст проект с импортированным WSDL, доступным в навигаторе. Перейдите прямо к первому запросу «Запрос 1», сгенерированному для операции Добавить , и дважды щелкните его, после чего откроется следующее окно:

Теперь все, что вам нужно сделать, это ввести два целых числа и нажать зеленую стрелку в левом верхнем углу, чтобы отправить запрос целевой службе, которая вернет вам хороший ответ:

Если вы используете профессиональную версию SoapUI или вам не нравится синтаксис XML, вы можете вместо этого использовать представление формы для запроса и обзор для ответа:

Вот и все, вы выполнили свой первый Ad-Hoc тест веб-службы SOAP, теперь погрузитесь в детали, чтобы понять все возможности!

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

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

SoapUI Pro

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

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

Работа с WSDL

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

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

API-интерфейсы SOAP и REST: понимание различий

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

Начало работы | Использование веб-службы SOAP

  плагины {
id 'org.springframework.boot 'версия' 2.5.2 '
id 'io.spring.dependency-management' версия '1.0.11.RELEASE'
идентификатор 'java'
}

группа = 'com.example'
версия = '0.0.1-SNAPSHOT'
sourceCompatibility = '1.8'

// тег :: конфигурации []
конфигурации {
jaxb
}
// end :: configurations []

репозитории {
mavenCentral ()
}

// тег :: wsdl []
task genJaxb {
ext.sourcesDir = "$ {buildDir} / created-sources / jaxb"
ext.classesDir = "$ {buildDir} / classes / jaxb"
ext.schema = "http: // localhost: 8080 / ws / countries.wsdl"

output.dir classesDir

doLast () {
проект.ant {
имя taskdef: "xjc", имя класса: "com.sun.tools.xjc.XJCTask",
путь к классам: configurations.jaxb.asPath
mkdir (каталог: sourcesDir)
mkdir (каталог: classesDir)

xjc (destdir: sourcesDir, schema: schema,
package: "com.example.consumingwebservice.wsdl") {
arg (значение: "-wsdl")
производит (dir: sourcesDir, включает: "** / *. java")
}

javac (destdir: classesDir, источник: 1.8, цель: 1.8, отладка: true,
debugLevel: "строки, переменные, исходный код",
путь к классам: configurations.jaxb.asPath) {
src (путь: sourcesDir)
include (имя: "** / *. java")
include (имя: "* .java")
}

copy (todir: classesDir) {
набор файлов (dir: sourcesDir, erroronmissingdir: false) {
исключить (имя: "** / *. java")
}
}
}
}
}
// конец :: wsdl []

dependencies {
// tag :: dependency []
реализация ('org.springframework.boot: spring-boot-starter-web-services') {
исключить группу: 'org.springframework.boot', модуль: 'spring-boot-starter-tomcat'
}
реализация 'org.springframework.WS: Spring-WS-Core '
// Для Java 11:
реализация 'org.glassfish.jaxb: jaxb-runtime'
реализация (файлы (genJaxb.classesDir) .builtBy (genJaxb))

jaxb "com.sun.xml.bind: jaxb-xjc: 2.1.7"
// end :: dependency []
testImplementation ('org.springframework.boot: Spring-boot-starter-test')
}

контрольная работа {
useJUnitPlatform ()
}

// тег :: bootjar []
bootJar {
baseName = 'gs-потребляющая-веб-служба'
версия = '0.0.1'
}
// конец :: bootjar []  

Как превратить любую веб-службу SOAP в REST API

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

Как работает SOAP и REST

Существует два типа удаленных веб-служб: REST API и SOAP. API

Если вы хотите обернуть SOAP API и упростить работу с помощью конечных точек REST, этот простой учебник позволит вам достичь этой цели.

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

Для кого это?

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

Есть много приложений, в которых вы, вероятно, найдете это полезным, и, фактически, почти каждая команда которая работает с такими API, вероятно, выиграет от прохождения этого простого процесса.

Как преобразовать SOAP в REST

Шаги действительно очень просты.

# 1 Найдите API

Начните с поиска API, с которым вы хотите работать.

Если вы начинаете с нуля, перейдите к Create и выберите SOAP Service , затем введите всю информацию. Дай это имя, ярлык и краткое описание перед тем, как сделать его активным.

Мы собираемся использовать пример с именем temp с меткой Temperature и кратким описанием, поясняющим что это сервис SOAP, способный выполнять преобразование температуры.

# 2 Определите URI WSDL

На базовом уровне все, что вам действительно нужно, это предоставить WSDL URI на вкладке Config для службы, которой вы являетесь. пытаюсь работать с.

В нашем примере мы будем использовать:

https://www.w3schools.com/xml/tempconvert.asmx?WSDL

Это простой общедоступный, который вы можете использовать. Это даст вам рабочий веб-сервис, обернутый REST и живущий. задокументировано с помощью Swagger.

# 3 Посмотреть документацию по API

Как только вы сохраните свой URI в DreamFactory, он создаст живые документы API в Swagger. которые полностью основаны на REST.

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

В нашем примере есть две конечные точки, обе из которых мы можем легко использовать непосредственно в DreamFactory. панель приборов.

# 4 Использование запросов

В нашем примере мы можем сделать быстрый запрос Get, чтобы узнать, что доступно. Это покажет нам такие вещи, как вызовы, которые мы можем сделать с помощью нашего API.

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

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

Зачем нужен этот метод?

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

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

Простота

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

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

Безопасность

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

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

Чтобы управлять этим, перейдите на страницу Roles и выберите одну из списка. На вкладке Access для определенной роли вы можете назначить службы роли, нажав значок + . Выберите услугу из раскрывающегося списка, чтобы назначить это.

Это дает вам ряд преимуществ безопасности при оборачивании SOAP API в конечных точках REST с DreamFactory. система.

Простое создание мыла и отдыха

При такой простой настройке вы можете взять любой WSDL и просто вставить этот URL-адрес WSDL.После сохранения ваших настроек, он автоматически сгенерирует конечные точки в Swagger. При этом ваши приложения просто смогут называть это REST API всякий раз, когда вы их используете. Он все сделает за вас!

DreamFactory стремится сделать процесс максимально простым и понятным. Этот учебник должен включить чтобы все было настроено и работало правильно, без задержек и препятствий. Шаги довольно простые следовать, пока вы делаете все в правильном порядке.

Помимо оболочки API-интерфейсов SOAP конечной точкой REST, DreamFactory поддерживает добавление API-интерфейсов REST поверх популярных такие базы данных как:

Что такое SOAP API: форматы, протоколы и архитектура

Время чтения: 12 минут

Каждый раз, когда вы входите на веб-сайт с помощью своей учетной записи 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 , с другой стороны, имеет свободную структуру, которая фокусируется на самих данных.Взгляните на изображение ниже, чтобы получить представление.

Вы видите, что многочисленные закрывающие теги в XML делают его намного длиннее. Спасибо PCMag за изображение.

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

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

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

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

Заголовки и элементы неисправности не являются обязательными

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

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

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

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

Пример сообщения SOAP. Источник изображения: IBM

Расширяемость 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. Источник изображения: Researchgate.net

Самое замечательное в 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, когда достигают сервера, они могут быть прочитаны только правильным процессом внутри этого сервера, а не самим правильным сервером. Поскольку на стороне сервера может произойти некоторая предварительная обработка данных до того, как сообщение достигнет назначенного процесса.

Вот как WS-Security работает со структурой сообщения

Витторио Берточчи, главный программный менеджер 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.

Как скажет вам большинство инженеров, нельзя напрямую сравнивать SOAP и REST, но поскольку оба подхода решают схожий набор проблем, вот краткое описание

Операции с сохранением состояния и без сохранения состояния. 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?

ГрафикQL

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

Создание запросов SOAP | Центр обучения Postman

Postman может выполнять различные типы HTTP-вызовов в дополнение к REST, в том числе к независимым от протокола службам, таким как SOAP и GraphQL.

Следующие шаги описывают, как сделать запрос SOAP в Postman.

Введите конечную точку SOAP

Откройте новую вкладку запроса в Postman и введите URL-адрес конечной точки SOAP в поле адреса. Попробуйте следующий пример, если у вас нет конкретной службы, в которую вы хотите позвонить:

  https://www.dataaccess.com/webservicesserver/NumberConversion.wso  

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

Выберите POST из раскрывающегося списка метода запроса.

Добавить данные о теле

На вкладке Body выберите raw и выберите XML из раскрывающегося списка.

Введите свой XML в поле ввода текста, как в следующем примере:

  

  <мыло: Тело>
    
       500 
    
  
  

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

Когда вы выбираете тип тела XML, Postman автоматически добавляет заголовок типа контента application / xml , но в зависимости от вашего поставщика услуг для запросов SOAP вам может потребоваться text / xml .Откройте запрос Заголовки и щелкните, чтобы отобразить скрытые заголовки.

Уточните в службе SOAP, нужен ли вам заголовок application / xml или text / xml . Если вам нужен заголовок text / xml , вам нужно будет переопределить настройку по умолчанию, добавленную Postman. Снимите флажок с заголовка Content-Type Postman, добавляемого автоматически, и добавьте новую строку с Content-Type Key и text / xml Value .Кроме того, вам нужно будет установить заголовок SOAPAction со значением (и кавычки) "#MethodName" . Без этого сервис вернет 500.

Отправьте заявку

Щелкните Отправить , чтобы позвонить в службу SOAP. Если ваш звонок будет успешным, вы увидите ответ в нижней вкладке Почтальона.

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

Ознакомьтесь с шаблоном SOAP, где вы найдете множество примеров запросов, которые вы можете опробовать в Postman.

Различия и преимущества двух широко используемых протоколов связи веб-служб — Stackify

Определение SOAP и REST

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

SOAP и REST: основные различия

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

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

Преимущества REST по сравнению с SOAP

Помимо использования HTTP для простоты, REST предлагает ряд других преимуществ по сравнению с SOAP:

• REST допускает большее разнообразие форматов данных, тогда как SOAP допускает только XML.
• В сочетании с JSON (который обычно лучше работает с данными и предлагает более быстрый синтаксический анализ), REST обычно считается более простым в использовании.
• Благодаря JSON REST предлагает лучшую поддержку клиентов браузера.
• REST обеспечивает превосходную производительность, особенно за счет кэширования неизменяемой и не динамической информации.
• Это протокол, который чаще всего используется для крупных сервисов, таких как Yahoo, Ebay, Amazon и даже Google.
• REST обычно быстрее и использует меньшую полосу пропускания. Также проще интегрироваться с существующими веб-сайтами без необходимости реорганизации инфраструктуры сайта. Это позволяет разработчикам работать быстрее, а не тратить время на переписывание сайта с нуля. Вместо этого они могут просто добавить дополнительные функции.

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

Попробуйте бесплатный профилировщик кода Prefix от Stackify, чтобы писать лучший код на своей рабочей станции. Префикс работает с .NET, Java, PHP, Node.js, Ruby и Python.

Преимущества мыла над REST

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

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

Другие преимущества SOAP:

• Стандартный протокол HTTP SOAP упрощает работу через брандмауэры и прокси-серверы без модификации самого протокола SOAP.Но поскольку он использует сложный формат XML, он обычно работает медленнее по сравнению с промежуточным программным обеспечением, таким как ICE и COBRA.
• Кроме того, хотя это редко требуется, некоторые варианты использования требуют большей надежности транзакций, чем то, что может быть достигнуто с помощью HTTP (что ограничивает REST в этой способности). Если вам нужны транзакции, совместимые с ACID, вам подойдет протокол SOAP.
• В некоторых случаях разработка служб SOAP может быть менее сложной по сравнению с REST. Для веб-служб, которые поддерживают сложные операции, требующие поддержки содержимого и контекста, проектирование службы SOAP требует меньше кода на уровне приложения для транзакций, безопасности, доверия и других элементов.
• SOAP обладает широкими возможностями расширения с помощью других протоколов и технологий. Помимо WS-Security, SOAP поддерживает WS-Addressing, WS-Coordination, WS-ReliableMessaging и множество других стандартов веб-сервисов, полный список которых вы можете найти на W3C.

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

Об Александре Альтватер

• Что такое нагрузочное тестирование? Как это работает, инструменты, руководства и многое другое — 5 февраля 2021 г.
• Americaneagle.com и ROC Commerce остаются впереди с Retrace — 25 сентября 2020 г.
• Новые цены Stackify: все, что вам нужно знать — 9 сентября 2020 г.
• ИННОВАТОРЫ ПРОТИВ COVID 19 Мэтт Уотсон, генеральный директор Stackify, советует предпринимателям сосредоточиться на вещах, которые делают их счастливыми, независимо от того, является ли работа огромным пожаром в мусорном контейнере — 2 сентября 2020 г.
• Stackify присоединяется к 2020 Inc.5000 Список самых быстрорастущих компаний — 25 августа 2020 г.

Краткое руководство по SOAP: как использовать SOAP API, когда это действительно необходимо | Лиззи Каллен Дэвисон

Потому что, несмотря на наши усилия в области REST, существует еще много API-интерфейсов SOAP.

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

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

Итак, вот небольшое руководство по работе с SOAP API. Веселиться!

Фото Даниэля Левиса Пелуси на Unsplash

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

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

Я собираюсь показать вам, как начать использовать SOAP API, на примере этой службы преобразования чисел в слова.

Подготовьте свой WSDL

WSDL (произносится как wizzdle ) — это сокращение от языка определения веб-сервисов. Это XML-файл, в котором описаны все методы, которые можно вызывать с помощью SOAP API. Вы будете использовать его, чтобы определить, что вы можете делать с API, какие данные вы можете передавать ему и что вы можете ожидать от него в ответ.

WSDL создается автоматически. Чтобы увидеть WSDL для службы SOAP, которую вы хотите использовать, добавьте ? Wsdl в конец URL-адреса службы.

Например, чтобы увидеть, что мы можем сделать со службой преобразования номеров, мы можем взглянуть на ее WSDL, расположенный здесь: https://www.dataaccess.com/webservicesserver/NumberConversion.wso?wsdl

Чтение WSDL

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

Взгляните на этот отрывок из преобразователя чисел в слова WSDL:

  
  
  
  
  
  
  
  
  
  
  
   
  
  
 < / xs: schema> 

Мы видим, что существует метод с именем NumberToWords , который принимает параметр с именем ubiNum , который, по словам WSDL, должен иметь тип xs: unsignedLong .Просматривая типы данных XML (например, в W3Schools), мы видим, что это означает, что это должно быть 64-битное целое число без знака.

Существует также определение ответа, который мы можем ожидать получить: NumberToWordsResponse , который возвращает строковый параметр с именем NumberToWordsResult . Звучит хорошо — это то, чего можно ожидать от службы, которая берет число и превращает его в слово.

Теперь мы знаем, с чем работаем, пора попробовать!

Выполнение запроса SOAP

Существует очень специфическая структура выполнения запроса SOAP.Запрос записывается в XML и отправляется через HTTP (или, что реже, очередь сообщений или, что шокирует, email ).

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

 POST /webservicesserver/NumberConversion.wso HTTP / 1.1 
 Хост: www.dataaccess.com 
 Content-Type: text / xml; charset = utf-8 
 Content-Length: length  
  
  
  
  12  
  
  
  

Мы делаем обычный HTTP-запрос POST, где содержимое тела представляет собой некоторый XML, который сообщает службе, что мы хотим сделать.

тело запроса, есть мыло : Конверт , который обертывает мыло : Тело , , в котором вы передаете метод, который хотите вызвать (здесь NumbertoWords ), и внутри этого любые параметры, метод требует.

Вы можете опробовать этот запрос с Postman, используя их удобное руководство по созданию запросов SOAP. Просто предупреждаю, потому что в руководстве Postman это неясно — убедитесь, что для Content-Type установлено значение «text / xml» в заголовке, а также в теле.

Вот ответ на запрос выше:

  
  
  
  
  двенадцать  
  
  
  

Формат очень похож на формат запроса, за исключением того, что на этот раз мы видим NumberToWordsResponse , который содержит NumberToWordsResult . В данном случае строка «двенадцать».

Уф, это было немного многословно. Не волнуйтесь, вы не нужно самому писать все свои запросы от руки.

Поиск библиотеки SOAP

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

Концепция с библиотеками SOAP обычно одинакова:

1. Создание клиента SOAP на основе URL-адреса WSDL
2. Вызов динамически созданных методов на клиенте

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