Soap это: гайд для тестировщика

Содержание

гайд для тестировщика — Разработка на vc.ru

12 970 просмотров

Всем привет! Меня зовут Дархан, я QA-инженер компании Creative. Сегодня подробно расскажу об архитектурном стиле REST и формате обмена сообщениями SOAP, в которых нужно шарить любому тестировщику. Статья оформлена в виде простого и понятного гайда – разберём теорию, немного углубимся в детали, а в конце потестим наши запросы на сайте-песочнице. Будет интересно, поэтому давайте начинать. На все вопросы отвечу в конце статьи и, если нужно, разберу ваши кейсы. Погнали!

Базовые понятия о SOAP

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

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

Информационный набор Extensible Markup Language (XML) используется для SOAP в качестве формата сообщений, а передача и их согласование происходит с помощью протоколов прикладного уровня – таких, как HTTP.

Фишки SOAP

Знакомимся с REST

RESTful API – это архитектурный стиль интерфейса прикладных программ (API), который использует HTTP-запросы для доступа и использования данных. Их можно использовать для GET, PUT, POST и DELETE, которые относятся к чтению, обновлению, созданию и удалению операций с ресурсами.

Как это работает?

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

Пользоваться можно уже готовыми моделями, самыми популярными сейчас стали Amazon S3, Cloud Data Management Interface (CDMI) и OpenStack Swift.

RESTful API использует команды для получения ресурсов. Состояние ресурса в любой момент времени называется представлением ресурса. RESTful API использует существующие методологии HTTP, определенные протоколом RFC 2616, такие как:

GET для получения ресурса.
PUT для изменения состояния или обновления ресурса, который может быть объектом, файлом или блоком.
POST для создания этого ресурса.
DELETE, чтобы удалить его.

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

Какие форматы данных поддерживает REST API:

REST или SOAP

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

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

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

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

А теперь давайте наконец-то потестим наши SOAP и REST запросы.

Тесты методом SOAP

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

Далее нужно зарегистрироваться. Качаем SOAP UI для генерации запросов XML здесь.

Затем создаём SOAP проект (илл.1, 2):

Иллюстрация 1

Иллюстрация 2

Указываем готовый WSDL , который прописан специально для тестирования SOAP-запросов (илл. 3).

WSDL – это стандартный формат для описания веб-службы.

Иллюстрация 3

Сам файл создается на основе XML-тегов (илл. 4):

Иллюстрация 4

Дальше SOAP UI генерирует для нас список методов, который был написан в WSDL файле (илл. 5):

Иллюстрация 5

Запустим метод doRegister и создадим юзера (илл. 6):

Иллюстрация 6

Ниже можно увидеть, что в списке есть юзер с именем Darkhan (илл. 7):

Иллюстрация 7

Тесты методом REST

Для этого нам нужно скачать postman, чтобы вызвать запрос.

Дальше берём из документации URL и меняем запрос на POST, чтобы создать юзера (илл. 8):

Иллюстрация 8

Когда вы всё написали, можем запускать наш запрос (илл. 9):

Иллюстрация 9

И, как показано выше, наш запрос отработал отлично и отдал 200 статус (илл. 10):

Иллюстрация 10

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

Применение SOAP при интеграции систем

Для начинающих аналитиков,

не имеющих опыта web-разработки

Смотреть запись вебинара

Историческая справка

В предыдущей статье мы говорили про то, что REST — это архитектурный стиль, который Рой Филдинг сформулировал в своей диссертации в 2000 году.

С протоколом SOAP дела обстоят несколько иначе.
SOAP — это не стиль, а протокол. Аббревиатура SOAP так и расшифровывается: Simple Object Access Protocol — простой протокол доступа к объектам. То есть правила передачи информации в SOAP строго стандартизированы, есть спецификация, которой нужно соответствовать.

SOAP появился 1998 году и был передан в организацию World Wide Web Consortium (W3C) — международная организация, которая курирует развитие интернета.

Почему разница в 2 года в появлении REST и SOAP так сказалась на их популярности?

Все просто — компания Microsoft активно вкладывала деньги в продвижении SOAP. На тот момент Microsoft активно продвигал свою новую платформу .NET (платформа, в которой все конфигурационные файлы представлены в формате XML, и используется протокол SOAP). Так вот, на рекламу этой платформы Microsoft потратил 200 млн долларов.

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

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

Жив ли еще SOAP?

Просмотрев статистику вакансий на сайте hh.ru, можно обнаружить, что примерно четверть вакансий аналитиков содержат требования к знанию SOAP, WSDL и, как следствие, XML. В основном это крупные компании, которые занимаются проектами более 10 лет (банки, телеком).

В чем разница между REST и SOAP?

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

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

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

Что из себя представляет SOAP
и когда его нужно использовать

Клиент-серверная архитектура приложения

В SOAP передача данных идет по протоколу HTTP, то есть также, как это происходит и в случает REST-запросов.

Давайте рассмотрим на примере. Если я зайду на сайт какой-нибудь биржи акций, то могу узнать курс интересующей меня акции. Откуда поступает эта информация? Давайте разберемся.

Клиент и сервер SOAP

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

По протоколу HTTP он обращается к серверу (назовем его HTTP-server).

На этом HTTP-сервере живёт приложение, которое отдает мне информацию, о том, что акция Facebook стоит, к примеру, 252 доллара. Однако, откуда само приложение, живущее на HTTP-сервере, знает стоимость акции?

А все очень просто — приложение в данном случае выступило как SOAP-client и запросило эту информацию на другом сервере (назовем его SOAP-server).

Взаимодействие SOAP-client и SOAP-server происходит по протоколу SOAP поверх HTTP. Что значит поверх? Это значит, что клиент и сервер общаются по протоколу HTTP, но по этому протоколу передаётся не просто стандартное сообщение HTTP, а некий конвертик с письмом, причем это письмо написано по правилам протокола SOAP.

То есть сайт, который передал мне информацию о Facebook, сам запросил SOAP-server (то есть биржу акций) по протоколу HTTP и вложил сообщение в конвертик SOAP.

Таким образом, информация о курсе акции пришла ко мне не напрямую с биржи, а через посредника — через SOAP-client.

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

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

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

Посмотреть программу курса

Стек протоколов веб-сервисов

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

Протоколы веб-сервисов

Когда мы работаем по сети, мы работаем с протоколами TCP/IP — это нижний, сетевой уровень протоколов. Весь интернет базируется на протоколе HTTP, который мы рассматривали в предыдущей статье. HTTP является просто транспортом, с помощью которого информация передается по сети.

Чтобы передать какое-либо сообщение по сети, оно должно соответствовать правилам протокола HTTP. А дальше в пакетик, передаваемый по протоколу HTTP, вкладывается сообщение по протоколу SOAP. И все это живет по правилам, описанным в файле WSDL.

Как выглядит xml-документ?

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

В качестве примера приведу записку, которую Анна пишет Марии: «Приходи ко мне в гости в воскресенье!». И заголовок: «Напоминалка» (Reminder). Здесь могла бы быть ещё подпись signature, но, как видите, подпись оказалась пустой, информация в теге не передана (такое тоже возможно).

Тег — это текстовая строка, завернутая в уголочки (<>).

Пример XML-документа

То есть, когда мы передаем XML-документ, мы информацию «заворачиваем» в теги. Они предназначены для того, чтобы объяснять, что лежит внутри. Теги бывают открывающие (перед текстовым содержимым) и закрывающие (начинается с символа «/»).

В HTML такие же теги, но они применяются немного по-другому: в языке XML эти теги предназначены для того, чтобы объяснить приложению, которое принимает сообщение, что именно вложено внутрь.

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

Что такое WSDL? В SOAP для описания своего сервиса нужно использовать строгие правила в виде файлов WSDL. Ниже мы разберем это подробнее, но вообще WSDL — это Web Services Description Language, ещё один язык описания веб-сервисов и доступа к ним.

Как устроен xml-документ?

Разберем приведенный ранее пример детальнее.

Первая строка документа — XML-декларация, она указывает на версию XML (version=»1.0″) и тип кодировки документа (encoding=»utf-8″).

XML-декларация всегда начинается с символов <?xml и заканчивается символами ?>.
Декларация должна располагаться в самом начале файла, то есть первым символом файла должна быть угловая скобка и никаких концов строки или пробелов.

Правильно оформленный XML соответствует правилам:

Каждый открывающий тег должен иметь соответствующий закрывающий тег.
Теги не могут перекрывать друг друга.
XML- документы должны иметь только один корневой элемент.
Регистр символов (верхний/нижний) для XML существенен.

Что ещё есть в xml-документе?
Всё XML-сообщение (наша записочка) заворачивается в так называемый корневой тег. В данном случае, корневым является тег note, который выделен зеленым.
Правильно оформленный XML это такой XML, который соответствует стандартам языка и может быть разобран приложением, то есть приложение его получит, проверит синтаксис и начнет разбирать.
Важно понимать, что приложение не будет разбирать XML если он не будет правильно оформлен. В этом случае приложение придёт к выводу, что XML повредили или подменили по дороге.
Если мы посмотрим на XML-документ внимательно, то сможем построить вот такое дерево:

Дерево XML-документа
То есть с точки зрения приложения XML представляет собой дерево, состоящее из узлов. Например на картинке вы можете видеть имена узлов: note, to, from, heading, body, signature.
Узлы вкладываются друг друга, и получается, что XML-документ можно представить в виде перевернутого дерева, только дерево растет вниз. Тeг note является корнем и в него вложены остальные теги, все они являются детьми этого корня. Кроме того, есть ещё текстовых узлы Мария, Анна и т. д.
Атрибуты элементов в XML
Теги могут содержать атрибуты, то есть мы можем вложить атрибуты в корневой тег. Посмотрите, информация о том, от кого записка (from) и кому (to) в приведенном ниже кусочке XML оформлена не как теги, а как атрибуты тега note.

Пример тега, содержащего атрибут
Смысл XML в том, что теги удобно обрабатывать, и вариант, когда вы вкладываете информацию в виде текстовых узлов внутри тегов, довольно устойчив к ошибкам.
Представьте себе, что по пути потеряется буква «r» в слове from. Если она потеряется только в одном месте, то посмотрев на первый тег, мы поймем, как должен называться второй, или во всяком случае мы поймём, где произошла ошибка.
Разговоры о том, что какая-то буква потерялась, не очень актуальны сейчас, так как современные протоколы обеспечивают целостную доставку. Данный пример призван продемонстрировать, что XML-документ в первую очередь создаётся для того, чтобы информацию вкладывать в теги.
Атрибуты — это пары имя/значение, поставленные в соответствие одному из элементов. Они должны находиться при открывающем теге, но не при закрывающем.
Атрибуты всегда должны иметь значение, даже если значением является всего лишь пустая строка. Значения атрибутов должны заключаться в кавычки. При этом согласно синтаксису XML допускаются как двойные, так и одинарные кавычки.
Если вам придется руками формировать XML-документ, никогда не пишите в одном документе и двойные и одинарные кавычки, просто потому что вам лень аккуратненько расставить однотипные, поскольку это может привести к ошибкам.
Пространства имён
Чтобы наглядно объяснить, что такое пространство имён, рассмотрим следующий пример.
Представьте себе, что по интернету ходят XML-документы, сформированные разными приложениями (собственно, так и происходит). Может случиться, что одно приложение использует тег table и второе тоже использует тег table, но уже совсем в другом смысле.
Например, в первом случае тег table — это текст, который используется в языке HTML для указания того факта, что дальше идет описание таблицы. А во втором — предназначен для того, чтобы описать африканский кофейный стол и его размеры.
Как сделать так, чтобы приложение определило, что это разные теги table?

XML-документы с тегом table
Чтобы раскрыть тему, давайте рассмотрим бытовую аналогию: как учителя различают детей, которые приходят в класс.
У себя дома имя мальчика Серёжи, скорее всего, является уникальным идентификатором. То есть, вероятнее всего, ни одного Серёжи в семье больше нет. Но когда Серёжа приходит в школу, он обнаруживает, что в классе ещё три Серёжи, и учителю их надо как-то различать.
Как это сделать? Как правило, в классе для этого используется фамилия ребенка. Но если в классе есть однофамильцы Серёжи? Что ж, и такое бывает. В этом случае отличать Серёж можно по их домашнему адресу.
Интересный момент: если учитель знает, что Серёжа Васильев живёт по этому адресу, а тут в класс приходит некая Аня Васильева, живущая по этому же адресу, то можно сделать логичный вывод, что, скорее всего, Серёжа и Аня — брат и сестра. Именно адрес и указывает учителю на то, какая это семья и где она живёт. В XML-документах точно такая же логика.
Если нам нужно определить пространство имён (семью), к которому относится тег, мы заводим специальный атрибут. Этот атрибут называется XML namespace, сокращенно xmlns. Именно в xmlns мы пишем адрес — то место, где публикуется стандарт стандарта языка (то есть в атрибуте xmlns указывается адрес документа, в котором явно описано, что такое table для документа HTML).
В случае с кофейным столиком мы, разумеется, пишем другой адрес. Интересно, что это может быть абсолютно любой адрес, он может даже не существовать на самом деле, поскольку используется только для идентификации. То есть, вот этот тег table живет по этому конкретному адресу, и там же живёт вся его семья.
Что из себя представляет семья тегов?
Правило такое: если тег, у которого указано пространство имён, содержит вложенные теги, то эти вложенные теги относятся к тому же пространству имён.
То есть наш кофейный столик — это теги:
name
width
lenght
table
Все они из одного семейства тегов, как те самые Серёжа и Анна, которые относятся к одной семье.
Поэтому для того, чтобы идентифицировать теги, используется атрибут — атрибут пространства имён xmlns.
Пространство имён записывается как атрибут и это тоже узел дерева, только узел другого типа. У него также есть текстовое содержимое, только это особое текстовое содержимое. В целом, это тоже XML-документ просто узлы здесь разные (элементные и атрибутные).
Сообщения SOAP
Для эффективной работы нам, аналитикам, вполне достаточно знания основ синтаксиса XML. И для того, чтобы разбираться с SOAP, приведенных знаний будет достаточно. Если же вы захотите углубиться в детали, то про XML стоит читать в первоисточнике, то есть на сайте W3C.
Ранее в примерах мы говорили про обмен данными между сайтом и биржей акций. Как это происходит?
Чтобы отправить запрос в биржу акций, нужно ответить на простой вопрос. Facebook и сайт биржи акций должны ответить «252.36» — это содержимое, которое надо передать. Протокол SOAP предполагает, что это текстовое содержимое вложено внутрь XML-тегов и прописано в стандарте в виде XML-дерева.

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

Запрос по протоколу SOAP
Давайте разберем на составляющие данный запрос.
Envelope и Body — теги, которые прописаны в протоколе SOAP. То есть, если вы отправляете запрос по протоколу SOAP, то у вас должен быть тег Envelope и вложенный в него тег Body. Это нужно просто запомнить.
SOAP-ENV — обозначение пространства имён, то есть теги Envelope и Body относятся к пространству имён SOAP-овского окружения и это не что иное, как краткое указание на то, что есть определенное семейство тегов. А где описывается пространство имён, мы разберем немного позже.
getQuote (получить котировку) — имя процедуры, которую мы хотим вызвать. Она относится уже к другому пространству имён, а именно «ns1».
«Faсebook» — это входной параметр, который мы передаем, и он завернут в тег Symbol. Обратите внимание на атрибут, который есть в этом теге «string» — он описывает, что передаваться должно не число, а строка.
Ответ по протоколу SOAP выглядит в виде дерева:

Ответ по протоколу SOAP
Согласно представленному дереву документов, ответ содержит «252. 36». Он завернут в тег Result. A Result, в свою очередь, завернут в getQuoteResponse (ответ в котором содержится котировка акций). Далее getQuoteResponse завернут в Body, а тот в свою очередь — в Envelope.
Web Services Description Language (WSDL)
Давайте теперь вернемся к WSDL — документу, благодаря которому приложение заранее знает, какие должны прийти данные внутри каких тегов.
Основные теги с которыми вы столкнетесь в описании WSDL-сервера:
Message — сообщения, используемые web-сервисом.
PortType — список операций, которые могут быть выполнены с
сообщениями.
Binding — способ, которым сообщение будет доставлено.

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

WSDL-файл
Operation — это тег, который описывает функции. То есть он указывает на имя функции и то, как должен выглядеть запрос и ответ.
Вложенные в operation теги input и output содержат информацию о входных и выходных параметрах функции. То есть getQuoteRequest — это запрос, который представляет собой строку и должен иметь вид числа с плавающей точкой.
Тег binding описывает все технические сведения, о том, что из себя представляет сервис.
Тег servisce описывает, где живет наш сервис. Если бы мы установили веб-сервисом на локальной машине, то адрес написали бы следующим образом: localhost/server1. php/.
Если вы захотите расписать WSDL в виде дерева, то получите следующую картину:

WSDL-файл в виде дерева
Корневой тег definitions содержит 2 тега message, описывающие входной и выходной параметры.
Далее идет тег portType, включающий в себя тег operation, который также описывает входной и выходной параметры. PortType же собирает вместе информацию из двух тегов message.
Тег binding описывает все технические особенности нашего сервера. Считается довольно сложным в прочтении для начинающих.
Тег service содержит описание нашего сервера.
Выводы
Главным недостатком SOAP является то, что при его использовании для передачи сообщений, он увеличивает их объём и снижает скорость обработки.
Мы смогли в этом убедиться на примере вопроса «Facebook» и ответа «252.36», которые требуют огромного количества тегов, в которые заворачивается вопрос.
Для того, чтобы еще раз сравнить SOAP и REST, я привела преимущества приложения, созданного на основании REST:
Надёжность (за счёт отсутствия необходимости сохранять информацию о состоянии клиента, которая может быть утеряна).
Производительность (за счёт использования кеша).
Масштабируемость.
Прозрачность взаимодействия между системами по сети.
Простота интерфейсов.
Портативность компонентов.
Лёгкость внесения изменений.
Способность эволюционировать, приспосабливаясь к новым требованиям.
Поясним несколько важных моментов. Если говорить о простоте интерфейсов, то разумеется REST проще, так как передает информацию в файле формата JSON, а формат JSON специально создан для языка JavaScript, на котором работает браузер.
Для SOAP необходимо специальное приложение, чтобы разобрать XML-документ, распарсить его, как говорят в ИТ-среде.
Относительно легкости внесения изменений хочется заметить: для того, чтобы изменить WSDL, мы, разумеется, можем изменить адрес, но это непросто. SOAP — консервативный протокол, он используется преимущественно в Legacy-системах, но, тем ни менее, знание SOAP пользуется достаточно большим спросом.
Курс Елены Бенкен
«Основы проектирования интеграций»
Курс для ИТ-аналитиков и проектировщиков, знакомых с техникой use cases (сценарии использования) и разработкой требований к качеству ПО,
которым необходимо разобраться в теме интеграций и
научиться проектировать взаимодействие ИТ-систем
Посмотреть программу курса
Вопросы
Вопрос:
Как создать тег Biding?
Ответ:
Аналитик не должен озадачиваться тем, как создавать тег binding. Это должен делать программист биржи акций, если мы запрашиваем у нее WSDL, а не программист приложения, в котором мы используем этот WSDL (то есть не программист сайта биржи акций).
Вопрос:
Как записаться на курс по проектированию интеграций ИТ-систем?
Вопрос:
Как происходит асинхронное взаимодействие по протоколу SOAP? Например, отправлен запрос, он будет несколько минут обрабатываться. Отправляется ли сообщение о том, что запрос получен и взят в работу?
Ответ:
Асинхронное взаимодействие — это когда вы отправляете запрос, а ваш клиент не ждет ответа, а продолжает что-то делать. Отправляется ли сообщение о том, что запрос взят в работу, зависит от того, как спроектирован и реализован сервер, то есть от программиста. Если сервер предусматривает ответ при получении запроса, то мы этот ответ увидим.
Елена Бенкен
Системный аналитик, Автор курсов и Преподаватель
Имеет опыт разработки ТЗ в тематике спутниковой связи, программ лояльности;
Многолетний опыт участия в разработке навигационных систем для космических аппаратов, проектировании и макетировании микроэлектронных устройств;
Автор учебных курсов по php, mysql, javascript, jquery, ajax, Linux;
Написала и издала в BHV книги «PHP, MySQL, XML. Программирование для Интернета», «AJAX. Программирование для Интернета»;
Выпускник Питерского политеха по специальности «физика космоса».
Подписаться на новые статьи
Что такое SOAP API: форматы, протоколы и архитектура
Время считывания: 12 минут
Каждый раз, когда вы заходите на веб-сайт с помощью своей учетной записи Facebook или перетаскиваете булавку на карту Google в приложении для заказа такси, используемое вами приложение связывается с Google или Facebook через веб-API. . API или интерфейс прикладного программирования — это форма соглашения между веб-службами о том, как они будут обмениваться данными, например. получить карту или учетные данные вашей учетной записи. Сами данные структурированы в сообщениях, которые системы посылают друг другу. Как только вы открываете, скажем, приложение Uber, ваш телефон отправляет запрос на сообщение в Google Maps, и Google сам возвращает карту.

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

Пришло время предостеречь: в этой статье используются технические термины, такие как сервер, клиент, протоколы и т. д. Несмотря на то, что большинство из них объяснено, если вы все еще не уверены, взгляните на нашу статью о веб-архитектуре для начинающих. . Это удобная отправная точка для тех из вас, кто только осваивает воду.
Что такое МЫЛО?
SOAP или Simple Objects Access Protocol — это протокол веб-коммуникации, разработанный для 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 отображаются в виде упакованного сообщения, состоящего из четырех элементов с определенными функциями для каждого из них.
Заголовки и элементы неисправности не являются обязательными
Конверт — это основной и существенный элемент каждого сообщения, который начинается и завершается сообщениями с его тегами, обволакивающими его, отсюда и название.
Заголовок (необязательный) определяет особенности, дополнительные требования к сообщению, например. аутентификация.
Тело включает запрос или ответ.
Fault (необязательно) показывает все данные обо всех ошибках, которые могут возникнуть во время запроса и ответа API.
Пример сообщения SOAP. Источник изображения: IBM
Расширяемость SOAP стандартными протоколами WS
Тем не менее, сам SOAP обеспечивает основные структурные элементы сообщения. Но это не диктует, что должно быть в заголовках и телах. По сути, вы можете настроить это содержимое по мере необходимости.
Но поскольку веб-приложения обычно решают общие наборы проблем, после выпуска SOAP основной протокол был дополнен многочисленными стандартными протоколами, которые определяют, как вы делаете что-то.
Все эти протоколы обычно имеют маркировку WS-(имя протокола), например. WS-безопасность, WS-надежный обмен сообщениями. Их предоставили разные организации, в том числе 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-Security
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, должны глубоко погрузиться во все процессы внутри протокола с его строго ограниченными правилами.
Недостаток гибкости. Мы упоминали, что API SOAP служит строгим договором между клиентом и сервером. Имея это в виду, эта жесткая схема SOAP требует дополнительных усилий для добавления или удаления свойств сообщения на обеих сторонах связи, на сервере и на клиенте. Это делает обновление запросов и ответов утомительным процессом и замедляет внедрение.
Начало работы с SOAP: ключевые источники
Если вы только начинаете разработку SOAP, вот основные ссылки, которые вам следует проверить:
Документация по SOAP — ключевой источник истины для тех, кто начинает работать с SOAP
Версии SOAP — поскольку было несколько итераций протокола, проверьте эти версии SOAP
WSDL — как использовать язык описания веб-служб и создавать документы WSDL
WS-Addressing — как добавить информацию о маршрутизации в заголовки SOAP
WS-ReliableMessaging — расширение, обеспечивающее доставку сообщений по назначению. Также помогает создавать цепочки сообщений
WS-Coordinate — координировать действия распределенных приложений
WS-Security — как включить защиту на уровне сообщений
WS-Atomic Transaction — как создавать сообщения КИСЛОТА -совместимый
Чем 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?
GraphQL
Электронный обмен данными (EDI)
REST и SOAP
REST и SOAP — это два разных подхода к онлайновой передаче данных. В частности, оба определяют, как создавать интерфейсы прикладного программирования (API), которые позволяют передавать данные между веб-приложениями. Передача репрезентативного состояния (REST) — это набор архитектурных принципов. Простой протокол доступа к объектам (SOAP) — это официальный протокол, поддерживаемый консорциумом World Wide Web (W3C). Основное отличие состоит в том, что SOAP — это протокол, а REST — нет.
Как правило, API придерживается либо REST, либо SOAP, в зависимости от варианта использования и предпочтений разработчика.
Загрузите руководство пользователя нашего API
REST — это набор архитектурных принципов, адаптированных к потребностям облегченных веб-сервисов и мобильных приложений. Поскольку это набор рекомендаций, реализация этих рекомендаций предоставляется разработчикам.
Когда запрос данных отправляется в REST API, это обычно выполняется через протокол передачи гипертекста (обычно называемый HTTP). После получения запроса API-интерфейсы, разработанные для REST (называемые RESTful API или веб-службами RESTful), могут возвращать сообщения в различных форматах: HTML, XML, обычный текст и JSON. JSON (объектная нотация JavaScript) предпочтительнее в качестве формата сообщения, потому что он может быть прочитан любым языком программирования (несмотря на название), удобен для чтения человеком и машиной и имеет небольшой вес. Таким образом, RESTful API более гибкие и их проще настроить.

Приложение называется RESTful, если оно соответствует 6 архитектурным рекомендациям. Приложение RESTful должно иметь:
Архитектуру клиент-сервер, состоящую из клиентов, серверов и ресурсов.
Взаимодействие клиент-сервер без сохранения состояния, означающее, что содержимое клиента не сохраняется на сервере между запросами. Вместо этого информация о состоянии сеанса хранится у клиента.
Кэшируемые данные для устранения необходимости в некоторых взаимодействиях клиент-сервер.
Единый интерфейс между компонентами, чтобы информация передавалась в стандартизированной форме, а не в соответствии с потребностями приложения. Это описывается Роем Филдингом, создателем REST, как «центральная особенность, которая отличает архитектурный стиль REST от других сетевых стилей».
Ограничение многоуровневой системы, при котором взаимодействие клиент-сервер может быть опосредовано иерархическими уровнями.
Код по запросу, позволяющий серверам расширять функциональные возможности клиента путем передачи исполняемого кода (хотя это также снижает видимость, что делает это необязательным правилом).
SOAP — это стандартный протокол, который изначально был разработан для того, чтобы приложения, созданные на разных языках и на разных платформах, могли обмениваться данными. Поскольку это протокол, он налагает встроенные правила, которые увеличивают его сложность и накладные расходы, что может привести к увеличению времени загрузки страницы. Однако эти стандарты также предлагают встроенные соответствия, которые могут сделать их предпочтительными для корпоративных сценариев. Встроенные стандарты соответствия включают безопасность, атомарность, согласованность, изоляцию и надежность (ACID), которые представляют собой набор свойств для обеспечения надежных транзакций базы данных.
Общие спецификации веб-сервисов включают:
Безопасность веб-сервисов (WS-безопасность) : стандартизирует способы защиты и передачи сообщений с помощью уникальных идентификаторов, называемых маркерами.
WS-ReliableMessaging : стандартизирует обработку ошибок между сообщениями, передаваемыми через ненадежную ИТ-инфраструктуру.
Адресация веб-сервисов (WS-адресация) : Упаковывает информацию о маршрутизации в виде метаданных в заголовках SOAP вместо того, чтобы хранить такую информацию глубже в сети.
Язык описания веб-служб (WSDL) : Описывает, что делает веб-служба, и где эта служба начинается и заканчивается.
Когда запрос данных отправляется в SOAP API, он может быть обработан через любой из протоколов прикладного уровня: HTTP (для веб-браузеров), SMTP (для электронной почты), TCP и другие. Однако после получения запроса возвращаемые SOAP-сообщения должны быть возвращены в виде XML-документов — языка разметки, который читается как человеком, так и машиной. Завершенный запрос к SOAP API не кэшируется браузером, поэтому к нему невозможно получить доступ позже без повторной отправки в API.
Многие устаревшие системы могут по-прежнему придерживаться SOAP, в то время как REST появился позже и часто рассматривается как более быстрая альтернатива в веб-сценариях.