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

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

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

Схема взаимодействия веб-приложений по протоколу SOAP

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

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

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

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

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

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

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

Атрибут actor задает конкретную конечную точку для сообщения. Атрибут encodingStyle устанавливает специфическую кодировку для элемента. По умолчанию SOAP-сообщение не имеет определенной кодировки.

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

<?xml version="1.0"?> <soap:Envelope xmlns_soap="http://www.w3.org/2003/05/soap-envelope/" soap_encodingStyle="http://www.w3.org/2003/05/soap-encoding"> <soap:Body> <m:GetPrice xmlns_m="https://online-shop.ru/prices"> <m:Item>Dell Vostro 3515-5371</m:Item> </m:GetPrice> </soap:Body> </soap:Envelope>

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

<?xml version="1.0"?> <soap:Envelope xmlns_soap="http://www.w3.org/2003/05/soap-envelope/" soap_encodingStyle="http://www. w3.org/2003/05/soap-encoding"> <soap:Body> <m:GetPriceResponse xmlns_m="https://online-shop.ru/prices"> <m:Price>37299</m:Price> </m:GetPriceResponse> </soap:Body> </soap:Envelope>

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

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

Отличия 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

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

Различия REST и SOAP / Хабр

val6852

10 янв 2020 в 10:04

Время на прочтение 3 мин

Количество просмотров

558K

Туториал

Перевод

Автор оригинала: Ranga Karanam

Эта вторая статья в серии постов о разработке REST API:

• Введение в REST API — RESTful веб-сервисы
• Различия REST и SOAP
• Разработка REST API — что такое Contract First (контракт в первую очередь)?
• Разработка REST API — что такое Code First (код в первую очередь)?
• REST API — Что такое HATEOAS?
• Рекомендации по REST API — примеры проектирования веб-сервисов на Java и Spring

В этой статье рассматриваются некоторые аспекты основных различий между REST и SOAP.

Упс… на самом деле, сравнивать их немного похоже на сравнение яблок с апельсинами, поскольку SOAP — это формат протокола, основанный на XML, тогда как REST — это архитектурный подход.

Вы изучите

• Что такое REST?
• Что такое SOAP?
• Чем отличаются REST и SOAP?

REST и SOAP

REST и SOAP на самом деле не сопоставимы. REST — это архитектурный стиль. SOAP — это формат обмена сообщениями. Давайте сравним популярные реализации стилей REST и SOAP.

• Пример реализации RESTful: JSON через HTTP
• Пример реализации SOAP: XML поверх SOAP через HTTP

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

• Специфика SOAP — это формат обмена данными. С SOAP это всегда SOAP-XML, который представляет собой XML, включающий:
  — Envelope (конверт) – корневой элемент, который определяет сообщение и пространство имен, использованное в документе,
  — Header (заголовок) – содержит атрибуты сообщения, например: информация о безопасности или о сетевой маршрутизации,
  — Body (тело) – содержит сообщение, которым обмениваются приложения,
  — Fault – необязательный элемент, который предоставляет информацию об ошибках, которые произошли при обработке сообщений. И запрос, и ответ должны соответствовать структуре SOAP.
• Специфика REST — использование HTTP в качестве транспортного протокола. Он подразумевает наилучшее использование функций, предоставляемых HTTP — методы запросов, заголовки запросов, ответы, заголовки ответов и т. д.

Формат обмена сообщениями

• В SOAP вы используете формат SOAP XML для запросов и ответов.
• В REST такого фиксированного формата нет. Вы можете обмениваться сообщениями на основе XML, JSON или любого другого удобного формата. JSON является самым популярным среди используемых форматов.

Определения услуг

• SOAP использует WSDL (Web Services Description Language) — язык описания веб-сервисов и доступа к ним, основанный на языке XML.
• REST не имеет стандартного языка определения сервиса. Несмотря на то, что WADL был одним из первых предложенных стандартов, он не очень популярен. Более популярно использование Swagger или Open API.

Транспорт

SOAP не накладывает никаких ограничений на тип транспортного протокола. Вы можете использовать либо Web протокол HTTP, либо MQ.

REST подразумевает наилучшее использование транспортного протокола HTTP

Простота реализации

RESTFful веб-сервисы, как правило, гораздо проще реализовать, чем веб-сервисы на основе SOAP.

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

По этому вопросу также имеется авторское видео.

Резюме

В этой статье мы подробно рассмотрели различия между REST и SOAP.

Дополнительное чтение

5 Courses to Learn RESTful Web Services With Java and Spring in 2019

10 API Testing Tips for Beginners (SOAP and REST)

Теги:

• rest
• api
• restful
• web-services

Хабы:

• API

Всего голосов 6: ↑4 и ↓2 +2

Комментарии 7

@val6852

Пользователь

404: Страница не найдена

Архитектура приложения

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

Что я могу сделать сейчас?

Если вы впервые посещаете TechTarget, добро пожаловать! Извините за обстоятельства, при которых мы встречаемся. Вот куда вы можете пойти отсюда:

Поиск

• Узнайте последние новости.
• Наша домашняя страница содержит последнюю информацию об архитектуре приложений.
• Наша страница «О нас» содержит дополнительную информацию о сайте, на котором вы находитесь, «Архитектура приложений».
• Если вам нужно, свяжитесь с нами, мы будем рады услышать от вас.

Просмотр по категории

Качество ПО

• Как создать набор регрессионных тестов

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

• Как сбалансировать доступ к данным и безопасность в финтех-тестировании

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

• Тестовые фреймворки и примеры для модульного тестирования кода Python

  Модульное тестирование является важным аспектом разработки программного обеспечения. Команды могут использовать Python для модульного тестирования, чтобы оптимизировать преимущества Python…

Облачные вычисления

• Преимущества и ограничения Google Cloud Recommender

  Расходы на облако могут выйти из-под контроля, но такие службы, как Google Cloud Recommender, предоставляют информацию для оптимизации ваших рабочих нагрузок. Но…

• Zadara выбирает нового генерального директора, поскольку основатель переходит на роль технического директора

  Йорам Новик, второй генеральный директор облачного стартапа Zadara, привносит в эту должность многолетний опыт руководства ИТ и рассказывает о …

• Как работает маршрутизация на основе задержки в Amazon Route 53

  Если вы рассматриваете Amazon Route 53 как способ уменьшить задержку, вот как работает этот сервис.

TheServerSide.com

• Смарт-контракты, блокчейн и децентрализованные вычисления

  Такие отрасли, как производство и финансы, обращаются к децентрализованным вычислительным технологиям в форме смарт-контрактов …

• Как избежать выгорания удаленного инженера-программиста

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

• JavaScript против TypeScript: в чем разница?

  TypeScript и JavaScript — две дополняющие друг друга технологии, которые лежат в основе как клиентской, так и серверной разработки. Вот…

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 должно иметь:

1. Архитектуру клиент-сервер, состоящую из клиентов, серверов и ресурсов.
2. Взаимодействие клиент-сервер без сохранения состояния, означающее, что содержимое клиента не сохраняется на сервере между запросами. Вместо этого информация о состоянии сеанса хранится у клиента.
3. Кэшируемые данные для устранения необходимости в некоторых взаимодействиях клиент-сервер.
4. Единый интерфейс между компонентами, чтобы информация передавалась в стандартизированной форме, а не в соответствии с потребностями приложения. Это описывается Роем Филдингом, создателем REST, как «центральная особенность, которая отличает архитектурный стиль REST от других сетевых стилей».
5. Ограничение многоуровневой системы, при котором взаимодействие клиент-сервер может быть опосредовано иерархическими уровнями.
6. Код по требованию, позволяющий серверам расширять функциональные возможности клиента путем передачи исполняемого кода (хотя это также снижает видимость, что делает это необязательным правилом).

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

Общие спецификации веб-сервисов включают:

• Безопасность веб-сервисов (WS-безопасность) : стандартизирует способы защиты и передачи сообщений с помощью уникальных идентификаторов, называемых маркерами.
• WS-ReliableMessaging : Стандартизирует обработку ошибок между сообщениями, передаваемыми через ненадежную ИТ-инфраструктуру.
• Адресация веб-сервисов (WS-адресация) : Упаковывает информацию о маршрутизации в виде метаданных в заголовках SOAP вместо того, чтобы хранить такую ​​информацию глубже в сети.
• Язык описания веб-служб (WSDL) : Описывает, что делает веб-служба, и где эта служба начинается и заканчивается.

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