Рельсы веб-интеграции. REST и SOAP

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

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,
• однозначность.

• сложность реализации;
• сложность/ресурсоемкость парсинга XML-данных.

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

Всё, что нужно знать о REST и SOAP: гайд для тестировщика

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

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

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

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

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

Фишки SOAP

• SOAP обладает высокой расширяемостью, но используется только те фрагменты, которые нужны для конкретной задачи.
• Частью волшебства является язык описания веб-служб (WSDL) – ещё один файл, связанный с SOAP. Он показывает, как работает веб-служба, поэтому при создании ссылки на нее среда IDE может полностью автоматизировать процесс.
• SOAP работает с XML, а другим языкам предоставляет ярлыки, которые могут ускорить и облегчить процесс создания запроса и анализа ответа.
• SOAP не терпит ошибок. И это не прикол! В некоторых языках программирования запросы и получение ответов в SOAP нужно будет создавать вручную, поэтому keep calm, please! Сложность зависит от языка программирования.

Знакомимся с 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:

• приложение/json.
• приложение/xml.
• приложение/x-wbe+xml.
• приложение/x-www-форма-urlencoded.
• multipart/form-data.

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):

SOAP API

SOAP — это протокол, по которому веб-сервисы взаимодействуют друг с другом или с клиентами. Название происходит от сокращения Simple Object Access Protocol («простой протокол доступа к объектам»). SOAP API — это веб-сервис, использующий протокол SOAP для обмена сообщениями между серверами и клиентами. При этом сообщения должны быть написаны на языке XML в соответствии со строгими стандартами, иначе сервер вернет ошибку.

Освойте профессию «Frontend-разработчик»

Появление, развитие и актуальность SOAP API

Протокол SOAP был представлен в 1998 году и быстро стал одним из главных стандартов веб-служб, когда Microsoft продвигала платформу .NET, приложения которой взаимодействовали с помощью SOAP API. Сейчас протокол и API уступают по популярности архитектурному стилю REST. Но веб-приложения, использующие SOAP API, все еще пользуются спросом, особенно в банковском и телекоммуникационном секторах.

Профессия / 9 месяцев
Frontend-разработчик

Создавайте интерфейсы сервисов, которыми пользуются все

Особенности SOAP API

SOAP может использоваться с протоколами SMTP, FTP, HTTP, HTTPS. Чаще всего — с HTTP как с наиболее универсальным: его поддерживают все браузеры и серверы. Корректное SOAP-сообщение состоит из нескольких структурных элементов: Envelope, Header, Body и Fault.

Envelope («конверт»). Это корневой элемент. Определяет XML-документ как сообщение SOAP с помощью пространства имен xmlns_soap=»http://www.w3.org/2003/05/soap-envelope/». Если в определении будет указан другой адрес, сервер вернет ошибку.

Header («заголовок»). Включает в себя атрибуты сообщения, связанные с конкретным приложением (аутентификация, проведение платежей и так далее). В заголовке могут использоваться три атрибута, которые указывают, как принимающая сторона должна обрабатывать сообщение, — mustUnderstand, actor и encodingStyle. Значение mustUnderstand — 1 или 0 — говорит принимающему приложению о том, следует ли распознавать заголовок в обязательном или опциональном порядке. Атрибут actor задает конкретную конечную точку для сообщения. Атрибут encodingStyle устанавливает специфическую кодировку для элемента. По умолчанию SOAP-сообщение не имеет определенной кодировки.

Body («тело»). Сообщение, которое передает веб-приложение. Может содержать запрос к серверу или ответ от него. Пример сообщения, которое запрашивает стоимость ноутбука в онлайн-магазине:

Пример ответа сервера онлайн-магазина:

Станьте Frontend-разработчиком
и создавайте интерфейсы сервисов, которыми пользуются все

Fault («ошибка»). Опциональный элемент. Передает уведомление об ошибках, если они возникли в ходе обработки сообщения. Может содержать вложенные элементы, которые проясняют причину возникновения ошибки:

• faultcode — код неполадки;
• faultstring — «человекопонятное» описание проблемы;
• faultactor — информация о программном компоненте, который вызвал ошибку;
• detail — дополнительные сведения о месте возникновения неполадки.

Читайте также Кто такой frontend-разработчик?

Отличия SOAP от REST

SOAP — протокол, а REST — архитектурный стиль, набор правил по написанию кода. REST был представлен в 2000 году. К этому времени недостатки SOAP были очевидны:

• объемные сообщения;
• поддержка только одного формата — XML;
• схема работы по принципу «один запрос — один ответ»;
• смена описания веб-сервиса может нарушить работу клиента.

Разработчик стиля REST Рой Филдинг учел недостатки SOAP. REST поддерживает несколько форматов помимо XML: JSON, TXT, CSV, HTML. Вместо создания громоздкой структуры XML-запросов при использовании REST чаще всего можно передать нужный URL. Эти особенности делают стиль REST простым и понятным, а приложения и веб-сервисы, использующие его, отличаются высокой производительностью и легко масштабируются.

Пример простого URL-запроса, возвращающего результаты поиска по ключевому слову DNA («ДНК»), можно посмотреть в международной базе научных статей.

Несмотря на простоту использования, у REST есть ряд недостатков, которые отсутствуют у SOAP:

• при использовании REST сложнее обеспечить безопасность конфиденциальных данных;
• трудности с проведением операций, которым необходимо сохранение состояния. Как, например, в случае с корзиной в онлайн-магазине, которая должна сохранять добавленные товары до момента оплаты.

Основные различия SOAP и REST API мы собрали в таблице для большей наглядности:

Особенности	SOAP API	REST API
Тип протокола	SOAP является протоколом сообщений.	REST является архитектурным стилем.
Протокол обмена данными	XML	Различные форматы, чаще всего JSON.
Транспортный протокол	Может использовать разные транспортные протоколы, но чаще всего использует HTTP, SMTP, TCP и т. д.	Использует преимущественно HTTP.
WS-* стандарты	SOAP поддерживает стандарты WS-Security, WS-ReliableMessaging, WS-AtomicTransaction и другие.	REST не определяет стандарты безопасности и надежности. Но может использовать дополнительные стандарты, если необходимо.
Stateful / Stateless	Может быть как stateful, так и stateless.	RESTful API обычно stateless.
Разработка	Более сложная разработка и более объемный размер сообщений из-за XML.	Проще разработка и более легкий размер сообщений благодаря JSON и другим легковесным форматам.
Кэширование	Обычно имеет ограниченную поддержку кэширования.	Поддерживает хорошее кэширование на уровне HTTP.
Модель безопасности	Следует стандартам WS-Security для безопасности.	Использует HTTPS для обеспечения безопасности. Также может использовать токены авторизации, как OAuth.
Поддержка	Имеет более широкую поддержку в старых системах и в предприятии.	Популярен в веб-приложениях и мобильных приложениях. Широко используется в RESTful веб-сервисах.

В каких случаях используют SOAP

• Асинхронная обработка и последующий вызов. Стандарт SOAP 1.2 обеспечивает клиенту гарантированный уровень надежности и безопасности.
• Формальное средство коммуникации. Если клиент и сервер имеют соглашение о формате обмена, то SOAP 1.2 предоставляет жесткие спецификации для такого типа взаимодействия. Пример — сайт онлайн-покупок, на котором пользователи добавляют товары в корзину перед оплатой. Предположим, что есть веб-служба, которая выполняет окончательный платеж. Может быть достигнуто соглашение, что веб-сервис будет принимать только название товара, цену за единицу и количество. Если сценарий существует, лучше использовать протокол SOAP.
• Операции с состоянием. Если приложение требует, чтобы состояние сохранялось от одного запроса к другому, то стандарт SOAP 1.2 предоставляет структуру для поддержки таких требований.

Frontend-разработчик

Научитесь создавать удобные и эффектные сайты, сервисы и приложения, которые нужны всем. Сегодня профессия на пике актуальности: в России 9000+ вакансий, где требуется знание JavaScript.

При подготовке материала использовались источники:
https://habr.com/ru/companies/intervolga/articles/591573/
https://vc.ru/dev/563668-vse-chto-nuzhno-znat-o-rest-i-soap-gayd-dlya-testirovshchika

SOAP API