🦒
System Analyst | Knowledge base
  • Введение
  • Soft skills
    • 📍Продукт
      • Роли в IT продукте
        • Системный аналитик (SA)
        • Бизнес-аналитик (BA)
        • SA vs BA
        • 📎Другие аналитики
      • Жизненный цикл продукта
      • Методологии разработки
        • Waterfall
        • Agile
          • Scrum
          • Kanban
      • 📎Целеполагание
        • SMART
        • Матрица Эйзенхауэра
        • RICE
        • 🔒HADI
    • 📍Требования
      • Классификация требований
        • Уровень: Бизнес
        • Уровень: Пользователь
          • Use case
          • User story
          • 📎Job story
        • Уровень: Продукт
          • Функциональные требования
          • Нефункциональные требования
      • Качества требований
      • Методы сбора требований
      • Техническое задание (ТЗ)
  • Hard skills
    • 📍Базы данных
      • Реляционные
        • Транзакции
          • 🔒CAP
        • Нормальные формы
        • SQL
          • DML
          • DDL/DCL/TCL
          • 📎Представления VIEW
        • Констрейты
        • 📎Типы данных
        • 🔒Middle+
          • Особенности работы с конкертными реляционными БД
      • Нереляционные
        • Примеры использования
        • 🔒Middle+
          • Колоночные
            • Сlickhouse
          • Ключ-значение
          • Матричные
          • Документо-ориентированные
          • Графовые
            • JanusGraph | Neo4j etc
      • Масштабирование БД
      • Оптимизация БД
        • 📎Типы индексов
        • 📎Уникальные индексы
        • 🔒Анатомия плана запроса
      • 📎Какую СУБД выбрать
      • 📎Хранение и анализ данных
        • ETL
        • DWH
          • DWH vs Data Lake vs Data Mart
        • OLAP
          • OLAP vs OLTP
        • BI-аналитика
    • 📍Интеграции
      • Форматы данных
        • JSON + JSON Schema
          • 🔒AVRO
        • JSON vs XML
      • Виды интеграций
        • Синхронное взаимодействие
          • REST
            • RESTful принципы
              • Отсутствие состояния (Авторизация)
                • 🔒OAuth / OpenID Connect
              • Кеширование
              • Единообразие интерфейса (CRUD)
                • Запрос/ответ
              • 🔒Cтепень зрелости REST API
            • Проектирование API
            • 📎Асинхронный REST
          • SOAP
            • XSD
            • WSDL
          • REST vs SOAP
        • Асинхронное взаимодействие
          • Kafka
          • RabbitMQ
          • Kafka vs RabbitMQ
          • ESB
          • gRPC
            • Правила proto-контракта
            • Protobuf vs JSON
            • Сравнительная таблица
          • Другое
          • 🔒WebSocket API
        • Sync vs Async
      • 🔒Middle+
        • Stateful vs Stateless
        • Apache Flink
        • оркестрация и хореография
    • 📍Проектирование
      • Архитектура
        • Монолит
        • Микросервисы
          • Паттерны реализации
        • Монолит vs Микросервисы
        • 🔒Middle+
          • Бессерверная
          • Сервис-ориентированная (SOA)
          • Другое
      • Нотации и диаграммы
        • UML
          • Диаграмма классов
          • Диаграмма последовательности
            • Фреймы
          • Диаграмма прецедентов (use case)
          • 🔒Middle+
            • Диаграмма деятельности/активности
            • Диаграмма состояний
        • BPMN
          • Основные элементы
        • BPMN vs UML
        • ERD
        • 📎IDEF0
      • Прототипирование
        • Figma vs Axure
      • Мониторинг
        • Логирование
        • Метрики
        • Алерты
        • 🔒Инструменты
          • Grafana
          • Prometheus
          • ELK
            • Elasticsearch
            • Logstash
            • Kibana
      • 🔐Системный дизайн
    • 📎DevOps for SA
      • Основы сетей
        • OSI
        • TCP/IP
        • HTTP
        • DNS
      • Git (VCS)
        • GitHub vs GitLab
      • Развертывание приложений
        • CI/CD
        • 🔒Middle+
          • Виртуализация/контеризация
            • ✍️Docker
            • Kubernetes
              • ✍️Openshift
      • Cloud Native
        • Сервисы облачных вычислений
        • Cloud-native app vs Traditional app
      • Командная строка
    • 📎QA for SA
      • Postman | Insomnia
      • Swagger
      • Верификация vs Валидация
      • Идентификация/Аутентификация/Авторизация
    • 📎PM for SA
      • Метрики
        • Метрики привлечения
        • Метрики вовлечённости
          • ARPU
          • LTV
          • NPV
          • ROI
          • NPS
      • Прокси метрики
      • Дерево метрик
      • Фреймворки
      • Юнит-экономика
      • Модель Кано
  • Другое
    • Литература
    • Советы по составлению резюме
    • Общие вопросы на собеседовании
    • Вопросы которые надо задать интервьюеру
  • Контакты
Powered by GitBook
On this page
  • Структура SOAP запроса
  • Envelope («конверт»)
  • Header («заголовок»)
  • Body («тело»)
  • Fault («ошибка»)
  • В каких случаях используют SOAP
  • Недостатки SOAP

Was this helpful?

  1. Hard skills
  2. Интеграции
  3. Виды интеграций
  4. Синхронное взаимодействие

SOAP

PreviousАсинхронный RESTNextXSD

Last updated 1 year ago

Was this helpful?

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

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

Структура 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

Пример сообщения, которое запрашивает стоимость ноутбука в онлайн-магазине:

<?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

  • В интеграции сложных систем. SOAP поддерживает передачу сложных объектов и атрибутов, что позволяет эффективно обмениваться данными между системами.

  • Когда есть необходимость в строгих стандартах безопасности с поддержкой SSL. SOAP API использует WS-Security для обеспечения безопасности приложений на уровне предприятия и для связи с унаследованными системами.

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

  • Когда необходимо сохранить конфиденциальность. SOAP API включает в себя соответствие стандарту ACID (Atomicity, Consistency, Isolation, and Durability) и это соответствие уменьшает избыточность и повышает безопасность и целостность сообщений.

Недостатки SOAP

  • Объемные сообщения: SOAP API использует XML для сериализации данных, что приводит к увеличению объема передаваемых сообщений. Проблемы возникают при передаче больших объемов данных или при работе с медленными сетевыми соединениями.

  • Поддержка только одного формата: SOAP API ограничен использованием только XML в качестве формата данных. В некоторых случаях это может означать дополнительные накладные расходы на преобразование данных из других форматов в XML и обратно.

  • Один запрос — один ответ (один end-point): клиент должен отправить запрос и дождаться ответа от сервера, прежде чем продолжить выполнение следующих операций. Это может привести к блокировке клиентского приложения, если запрос долго обрабатывается.

  • Возможность нарушения работы клиента при смене описания веб-сервиса: смена описания потребует дополнительных усилий для согласования изменений между поставщиком и потребителем сервиса.

Источники:

📍
WSDL
https://habr.com/ru/companies/itq_group/articles/705598/
https://blog.skillfactory.ru/glossary/soap-api/
https://elbrusboot.camp/blog/soap-api/