что такое soap api простыми словами
Что такое SOAP?
Объясните, пожалуйста, простыми словами, что такое SOAP, для чего нужен, и, если можно, пару примеров использования.
6 ответов 6
Лирическая часть.
Представьте что у вас реализована или реализуется некая система, которая должна быть доступна извне. Т.е. есть некий сервер, с которым вам надо общаться. Например веб-сервер.
Этот сервер может выполнять множество действий, работать с базой, выполнять какие-то сторонние запросы к другим серверам, заниматься каким-то вычислениями и т.д. жить и возможно развиваться по ему известному сценарию (т.е. по сценарию разработчиков). С таким сервером общаться человеку неинтересно, потому что он может не уметь/не хотеть отдавать красивые странички с картинками и прочим юзер-френдли контентом. Он написан и работает чтобы работать и выдавать на запросы к нему данные, не заботясь, чтоб они были человекочитаемые, клиент сам с ними разберется.
Практическая часть.
Веб-сервис (так называется то, что предоставляет сервер и то, что используют клиенты) дает возможность общения с сервером четко структурированными сообщениями. Дело в том, что веб-сервис не принимает абы какие данные. На любое сообщение, которое не соответствует правилам, веб-сервис ответит ошибкой. Ошибка будет, кстати, тоже в виде xml с четкой структурой (чего нельзя сказать правда о тексте сообщения).
WSDL (Web Services Description Language). Правила, по которым составляются сообщения для веб-сервиса описываются так же с помощью xml и также имеют четкую структуру. Т.е. если веб-сервис предоставляет возможность вызова какого-то метода, он должен дать возможность клиентам узнать какие параметры для данного метода используются. Если веб-сервис ждет строку для метода Method1 в качестве параметра и строка должна иметь имя Param1, то в описании веб-сервиса эти правила будут указаны.
Для клиентов достаточно знать url веб-сервиса, wsdl всегда будет рядом, по которому можно получить представление о методах и их параметрах, которые предоставляет этот веб-сервис.
Какие плюсы у всех этих наворотов:
Описание, имеющее четкую структуру, читается любым soap-клиентом. Т.е. какой бы ни был веб-сервис, клиент поймет какие данные веб-сервис принимает. По этому описанию клиент может построить свою внутреннюю структуру классов объектов, т.н. binding’и. В итоге программисту, использующему веб-сервис, остается написать что-то типа (псевдокод):
Минусов тоже полно:
В качестве примера есть открытый веб-сервис belavia:
Можете вручную создать и послать запрос типа:
ЗЫ Раньше был открыт веб-сервис аэрофлота, но после того как 1C добавили поддержку soap в 8ку, куча 1с-бета-тестеров с успехом положили его. Сейчас что-то там поменяли (адреса не знаю, можно поискать, если интересно).
ЗЗЫ Дисклеймер. Рассказал на бытовом уровне. Пинать можно.
Что такое soap api простыми словами
Eсть два основных подхода к построению программного интерфейса веб-приложений: REST (RESTful) API и SOAP API:
Подробнее:
REST (Representational State Transfer — «передача состояния представления») — архитектурный стиль взаимодействия компонентов распределённого приложения в сети.
REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиа-системы. В определённых случаях (интернет-магазины, поисковые системы, прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. В широком смысле компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во Всемирной паутине.
В сети Интернет вызов удалённой процедуры может представлять собой обычный HTTP-запрос (обычно «GET» или «POST»; такой запрос называют «REST-запрос»), а необходимые данные передаются в качестве параметров запроса.
Для веб-служб, построенных с учётом REST (то есть не нарушающих накладываемых им ограничений), применяют термин «RESTful».
В отличие от веб-сервисов (веб-служб) на основе SOAP, не существует «официального» стандарта для RESTful веб-API.
REST является архитектурным стилем, в то время как SOAP является протоколом. Несмотря на то, что REST не является стандартом сам по себе, большинство RESTful-реализаций используют стандарты, такие как HTTP, URL, JSON и XML.
Требования архитектуры REST:
5. Слои
Клиент обычно не способен точно определить, взаимодействует он напрямую с сервером или же с промежуточным узлом, в связи с иерархической структурой сетей (подразумевая, что такая структура образует слои). Применение промежуточных серверов способно повысить масштабируемость за счёт балансировки нагрузки и распределённого кэширования. Промежуточные узлы также могут подчиняться политике безопасности с целью обеспечения конфиденциальности информации.
6. Код по требованию (необязательное ограничение).
REST может позволить расширить функциональность клиента за счёт загрузки кода с сервера в виде апплетов или сценариев.
Приложения, не соответствующие приведённым условиям, не могут называться REST-приложениями.
Если же все условия соблюдены, то приложение получает следующие преимущества:
Преимущества:
• Надёжность (за счёт отсутствия необходимости сохранять информацию о состоянии клиента, которая может быть утеряна);
• Производительность (за счёт использования кэша);
• Масштабируемость;
• Прозрачность системы взаимодействия (особенно необходимая для приложений обслуживания сети);
• Простота интерфейсов;
• Портативность компонентов;
• Лёгкость внесения изменений;
• Способность эволюционировать, приспосабливаясь к новым требованиям (на примере Интернет).
SOAP (Simple Object Access Protocol — простой протокол доступа к объектам) — протокол обмена структурированными сообщениями в распределённой вычислительной среде.
Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур. Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур.
SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.
SOAP является одним из стандартов, на которых базируются технологии веб-служб.
Рельсы веб-интеграции. REST и SOAP
В каждой отрасли бизнеса, каждой компании, как правило, используется целый зоопарк ПО, например: сайт на 1С-Битрикс, CRM 1С-Битрикс24, учетная система на базе 1С. Одни системы “из коробки” умеют взаимодействовать с «соседними» продуктами, другие же приходится дорабатывать. За десятилетия существования веба как отрасли сформировались следующие практики межсетевого взаимодействия:
Обмен файлами по FTP.
Неструктурированные HTTP-запросы, договорённости между разработчиками.
Экзотика: сокеты, порты, бинарные объекты.
В данной статье мы поговорим о веб-сервисах. Чем они отличаются от прочих способов и какие они бывают.
Что такое веб-сервисы?
Веб-сервисы (или веб-службы) — это технология, позволяющая системам обмениваться данными друг с другом через сетевое подключение. Обычно веб-сервисы работают поверх протокола 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 (Simple Object Access Protocol) — Данные передаются в формате XML.
отраслевой стандарт по версии W3C;
наличие строгой спецификации;
широкая поддержка в продуктах Microsoft,
сложность/ресурсоемкость парсинга XML-данных.
Любое сообщение в протоколе SOAP — это XML документ, состоящий из следующих элементов (тегов):
Envelope. Корневой обязательный элемент. Определяет начало и окончание сообщения.
Header. Необязательный элемент — заголовок. Содержит элементы, необходимые для обработки самого сообщения. Например, идентификатор сессии.
Body. Основной элемент, содержит основную информацию сообщения. Обязательный.
Fault. Элемент, содержащий информацию об ошибках, возникающих в процессе обработки сообщения. Необязательный.
Пример SOAP запроса:
Пример SOAP ответа:
REST (Representational State Transfer) — на самом деле архитектурный стиль, а не протокол. В отличие от SOAP, REST не подкреплен официальным стандартом. Фактически, он основывается на соглашениях. Веб-сервис, построенный с учетом всех требований и ограничений архитектурного стиля, можно назвать RESTful веб-сервисом.
REST не использует конвертацию данных при передаче, данные передаются в исходном виде — это снижает нагрузку на клиент веб-сервиса, но увеличивает нагрузку на сеть. Управление данными происходит с помощью методов HTTP:
GET — получить данные;
POST — добавить данные;
PUT — изменить данные;
DELETE — удалить данные.
экономичность в плане ресурсов;
не требует программных надстроек (json_decode есть почти в каждом языке).
неоднозначность методов управления данными.
Пример REST запроса:
Пример REST ответа:
Что же использовать?
Вопрос “Какой способ реализации использовать?” необходимо рассматривать в контексте реализуемой системы и ее ограничений. Обычно, SOAP используется в крупных корпоративных системах со сложной логикой, когда требуются четкие стандарты, подкрепленные временем. XML-RPC, пожалуй, устарел и не имеет смысла ввиду наличия собрата JSON-RPC. RPC-протоколы подойдут для совсем простых систем с малым количеством единиц информации и API-методов.
Если же вы разрабатываете публичное API и логика взаимодействия во многом покрывается четверкой методов CRUD — смело выбирайте REST. Он наиболее популярен в WEB. Яндекс, Google и другие используют именно его для своего API.
Веб-сервисы в Битрикс
Веб-сервисы в живом производстве
Разработка веб-сервисов — типичная задача интеграции. ИНТЕРВОЛГА, как веб-интегратор, регулярно сталкивается с задачами разработки веб-сервисов и успешно с ними справляется. Наши сайты были и SOAP/REST серверами, и SOAP/REST клиентами.
Еще один личный кабинет для клиентов компании Евраз — еще один пример сайта в качестве клиента удаленного SOAP веб-сервиса.
Если у вас есть потребность организовать взаимодействие с веб-сервисом, сделать из сайта REST/SOAP/RPC клиент или сервер, обращайтесь к нам.
Подведем итог, выделив, два важных тезиса в пользу выбора веб-сервисов в качестве «рельс» для веб-интеграции.
Наш опыт неоднократно демонстрировал, что создание веб-сервисов, в реальном времени передающих необходимые данные между сайтом и другим ПО — лучшее решение, чем классические обмены по расписанию. Такой подход проще сопровождать, вести его отладку, это более эффективная трата времени программиста, чем проектирование и разработка сложного двунаправленного обмена с кучей сущностей.
Можно провести аналогию с эволюцией разработки сайтов. Когда-то, на заре сайтостроения, каждый разработчик делал сайт с нуля на той технологии, которую мог знать лишь он один. Это порождало проблемы в развитии таких сайтов. Как работали такие сайты — знал только автор кода. Со временем появлялись фреймворки и CMS. Разработку начинали не с нуля, а с известных широкой массе разработчиков “заготовок” — стандартных решений стандартных проблем с возможность расширения и углубления.
Также и с обменом данными. Не нужно тратить месяцы на объяснение новому сотруднику и самому себе, как работает обмен. Есть стандарт, обмен работает по нему.
REST API: минимум, который нужно знать новичку
Что такое программный интерфейс приложения (API)
Перед тем, как начать разговор о REST API, давайте вспомним, что такое API и для чего он нужен. API расшифровывается как Application Program Interface — программный интерфейс приложения. Данное понятие применимо не только к веб-разработке, но и к любым программным продуктам вообще. Наушники, микроволновые печи, телевизоры, микропроцессоры — все они имеют свой API.
Предположим, мы имеем дело с двумя такими совершенно разными разработками, каждая из которых обладает своим собственным API. Эти системы должны как-то взаимодействовать между собой, но есть некоторая сложность — ведь каждая из систем разработана на своем языке, по своим стандартам, со своими драйверами, на своей операционной системе и так далее. Чтобы как-то привести эти системы к общему знаменателю и иметь возможность коммуникации, мы используем API как некие внешние рычаги, которые влияют на внутреннее состояние каждой из систем. По этому принципу работает огромное количество проектов.
REST API — частный случай API
Допустим, мы написали сайт на PHP (Python, Java — не принципиально). PHP генерирует контент на сервере и по сети нам отправляет обратно уже сгенерированный HTML, JavaScript и CSS. Создавая сайт на PHP, вы получили некую статику, напрямую связывая код PHP, стили, HTML. Он взаимодействует с базой данных и выводит данные в шаблон. Предположим, мы задались целью разработать мобильное приложение под данную систему. Мобильное приложение должно работать с той же базой данных и мы должны как-то присоединить его к уже существующей системе.
Раньше многие шли по такому пути — создавали API для системы «сайт плюс база данных», и мобильное приложение работало через API или непосредственно через сам сайт. Но поддерживать и расширять такую концепцию было неудобно, поэтому постепенно перешли к варианту, когда используется связка backend и frontend. Backend по-прежнему работает с базой данных, а frontend является вообще отдельным приложением, которое, грубо говоря, ничего не знает про backend. Frontend является абстрагированный клиентом и может быть написан на Angular, React, Vue или просто на JavaScript.
Если для сайта имеется мобильное приложение, оно также относится к разряду клиентов и общается с backend-частью посредством API. При такой схеме клиентов может быть сколько угодно — мобильный клиент для Android, приложение под iOS, десктопное приложение, админка сайта и т. д. Частным случаем такой организации является REST API (Representational State Transfer) — некий стандартизированный протокол, позволяющий перемещать state и обмениваться им по API. Впервые его описал в своей диссертации Рой Филдинг. В ней он предложил соединять разные части программы либо сервисы по HTTP.
Критерии RESTful-приложения
Rest — это обычный запрос клиент-сервер с использованием HTTP протокола. В роли клиента не обязательно выступает браузер, это может быть мобильное приложение, десктопное приложение или же другой веб-сайт. В качестве ответа сервер выдает не привычную html-страницу, а просто набор данных, оформленных в том или ином формате. Чаще всего это JSON или XML. Неразрывно с REST следует AJAX (Asynchronous Javascript and XML).
Речь идет об отправке с браузера асинхронных запросов к серверу с помощью JavaScript. XML в данном случае не актуален, а процесс асинхронного общения браузера и веб-сервера задается именно REST-правилами. Веб-сервисы, которые полностью соответствуют парадигме Representational State Transfer, обычно называются RESTful. Чтобы приложение было RESTful, оно должно удовлетворять следующим правилам:
SOAP API — стандарт–предшественник REST API
Хотя на REST API и накладываются эти ограничения, он считается более простым в использовании, чем предшествующий ему протокол SOAP (простой протокол доступа к объектам). Последний выдвигает определенные требования, такие как обмен сообщениями XML, а также встроенные средства безопасности и соответствия транзакциям, что делает его медленнее и тяжеловеснее.
При отправке запроса данных в SOAP API, данные могут обрабатываться через любой из протоколов прикладного уровня: HTTP (для веб-браузеров), SMTP (для электронной почты), TCP и прочие. SOAP использует HTTP как транспортный протокол, в то время как REST базируется на нем. Как только запрос получен, возвращаемые сообщения SOAP должны быть переданы в виде XML-документов — языка разметки, который может считываться как человеком, так и машиной. Завершенный запрос к SOAP API не кэшируется браузером, поэтому он не может быть доступен вторично без повторной отправки в API. На данный момент SOAP — это устаревший стандарт, тем не менее довольно часто используемый enterprise-системами.
Типы запросов
Благодаря тому, что REST API построен поверх HTTP, не важно на каком языке написан frontend (JavaScript или Swift) и backend (Python, Java, C# и пр.), все они смогут взаимодействовать с данным протоколом. Каждый ресурс в REST должен быть идентифицирован посредством стабильного идентификатора, который не меняется при изменении состояния ресурса. Идентификатором в REST является URI. При помощи URL REST API сервер понимает с какими объектами работает, какие объекты ему нужно получить и какие объекты следует удалить.
REST API активно использует методы HTTP протокола и его статуса. В нем присутствуют несколько основных типов запросов:
Если мы говорим о REST как о бизнес-логике, то у нас есть объект и мы передаем статус этого объекта. Например, у нас есть сайт пиццерии и новый заказ. Мы можем заказ создать, узнать о нем подробности, можем обновить его или удалить. И чаще всего для этого используется формат JSON.
Коды запросов
Структура запроса включает в себя маршрут запроса, тип метода, заголовки и тело сообщения. Каждый запрос REST API сопровождается цифровыми кодами. Такие коды называются HTTP-статусами. Они сообщают об успешности запроса.
Статусы разделены на пять групп по своему значению:
Например, редактирование записи на сервере может выполнено успешно (код 200), может быть заблокировано контролем безопасности (код 401 или 403), или не пройти вообще из-за ошибки сервера (код 500).
Чтобы работать с REST API сервисами можно использовать такие инструменты как Postman, SOAP UI (open source утилита по работе с сервисами) и Curl — утилита командной строки, присутствует почти на всех Linux-компьютерах.
Недостатки REST API
Минус этого архитектурного стиля состоит в том, что он завязан на HTTP. Спецификация HTML имеет ограничения и формы, отправляющие данные могут быть реализованы только через GET или POST. Поэтому для корректной работы с другими методами их приходится имитировать. Например, в Rack (механизм на базе которого Ruby взаимодействует с веб-сервером; с использованием Rack сделаны Rails, Merb и прочие Ruby-фреймворки) в форму можно прописать hidden-поле с именем “_method”, а в качестве значения указать имя метода (скажем, «PUT») — при этом будет отправлен POST-запрос, но Rack сможет сделать вид, что получил PUT, а не POST.
Заключение
Теперь вы знаете, что такое REST API и где он применяется. Если говорить понятными словами — это возможность сервера давать доступ клиенту к своим ресурсам. Главный плюс REST API — его простота. Обращение REST API мало чем отличается от обычного запроса к веб-сайту (с небольшим расширением и описанием набора правил, как эти запросы будет происходить).
Недостатком REST API является то, что он опирается на спецификацию HTTP-протокола. Сам по себе REST API не является стандартом, это архитектурный подход. Из этого следует, что он может сильно отличаться у разных компаний. REST удобно использовать в простых случаях и когда важна скорость работы — при работе с мобильным устройством, с JavaScript. В сложных случаях, когда критична поддержка валидации, транзакции — используется SOAP. Помимо REST API имеются и иные способы создания API-систем, такие как JSON-RPC, XML-RPC и GraphQL. Однако на данный момент архитектурный стиль REST API остается самым популярным.
Детальное описание всех кодов REST-запросов (справочник) можно найти здесь — https://restapitutorial.ru/httpstatuscodes.html
Подробнее о REST-проектах, построенных с применением данного архитектурного стиля, а также их отличиях от SOAP сервисов можно узнать из видео ниже:
SOAP — Краткое руководство
SOAP — это сокращение от Simple Object Access Protocol. Это протокол обмена сообщениями на основе XML для обмена информацией между компьютерами. SOAP является приложением спецификации XML.
Указывает на заметку
SOAP — это протокол связи, предназначенный для связи через Интернет.
SOAP может расширить HTTP для обмена сообщениями XML.
SOAP обеспечивает транспорт данных для веб-сервисов.
SOAP может обмениваться полными документами или вызывать удаленную процедуру.
SOAP может использоваться для трансляции сообщения.
SOAP не зависит от платформы и языка.
SOAP — это способ определения, какая информация отправляется и каким образом.
SOAP позволяет клиентским приложениям легко подключаться к удаленным службам и вызывать удаленные методы.
SOAP — это протокол связи, предназначенный для связи через Интернет.
SOAP может расширить HTTP для обмена сообщениями XML.
SOAP обеспечивает транспорт данных для веб-сервисов.
SOAP может обмениваться полными документами или вызывать удаленную процедуру.
SOAP может использоваться для трансляции сообщения.
SOAP не зависит от платформы и языка.
SOAP — это способ определения, какая информация отправляется и каким образом.
SOAP позволяет клиентским приложениям легко подключаться к удаленным службам и вызывать удаленные методы.
Хотя SOAP может использоваться в различных системах обмена сообщениями и может доставляться через различные транспортные протоколы, первоначальная цель SOAP — удаленные вызовы процедур, транспортируемые через HTTP.
Другие платформы, в том числе CORBA, DCOM и Java RMI, предоставляют функциональность, аналогичную SOAP, но сообщения SOAP написаны полностью на XML и поэтому уникально независимы от платформы и языка.
SOAP — структура сообщения
SOAP-сообщение — это обычный XML-документ, содержащий следующие элементы:
Конверт — определяет начало и конец сообщения. Это обязательный элемент.
Заголовок — содержит любые необязательные атрибуты сообщения, используемые при обработке сообщения, либо в промежуточной точке, либо в конечной конечной точке. Это необязательный элемент.
Тело — содержит данные XML, содержащие отправляемое сообщение. Это обязательный элемент.
Неисправность — необязательный элемент неисправности, который предоставляет информацию об ошибках, возникающих при обработке сообщения.
Конверт — определяет начало и конец сообщения. Это обязательный элемент.
Заголовок — содержит любые необязательные атрибуты сообщения, используемые при обработке сообщения, либо в промежуточной точке, либо в конечной конечной точке. Это необязательный элемент.
Тело — содержит данные XML, содержащие отправляемое сообщение. Это обязательный элемент.
Неисправность — необязательный элемент неисправности, который предоставляет информацию об ошибках, возникающих при обработке сообщения.
ПРИМЕЧАНИЕ. — Все эти характеристики могут быть изменены. Так что продолжайте обновлять себя новейшими спецификациями, доступными на сайте W3.
Структура сообщения SOAP
Следующий блок отображает общую структуру сообщения SOAP —
МЫЛО — Конверт
Конверт SOAP указывает начало и конец сообщения, чтобы получатель знал, когда было получено все сообщение. Конверт SOAP решает проблему определения того, когда вы получили сообщение и готовы его обработать. Поэтому конверт SOAP — это, по сути, механизм упаковки.
Указывает на заметку
Каждое сообщение SOAP имеет корневой элемент Envelope.
Конверт является обязательной частью сообщения SOAP.
Каждый элемент Envelope должен содержать ровно один элемент Body.
Если конверт содержит элемент заголовка, он должен содержать не более одного элемента и должен отображаться как первый дочерний элемент конверта перед телом.
Конверт изменяется при изменении версий SOAP.
Конверт SOAP указывается с использованием префикса пространства имен ENV и элемента Envelope.
SOAP-процессор, совместимый с v1.1, генерирует ошибку при получении сообщения, содержащего пространство имен конверта v1.2.
SOAP-процессор, совместимый с v1.2, генерирует ошибку VersionMismatch, если он получает сообщение, которое не включает пространство имен конверта v1.2.
Каждое сообщение SOAP имеет корневой элемент Envelope.
Конверт является обязательной частью сообщения SOAP.
Каждый элемент Envelope должен содержать ровно один элемент Body.
Если конверт содержит элемент заголовка, он должен содержать не более одного элемента и должен отображаться как первый дочерний элемент конверта перед телом.
Конверт изменяется при изменении версий SOAP.
Конверт SOAP указывается с использованием префикса пространства имен ENV и элемента Envelope.
SOAP-процессор, совместимый с v1.1, генерирует ошибку при получении сообщения, содержащего пространство имен конверта v1.2.
SOAP-процессор, совместимый с v1.2, генерирует ошибку VersionMismatch, если он получает сообщение, которое не включает пространство имен конверта v1.2.
v1.2-совместимое сообщение SOAP
Ниже приведен пример сообщения SOAP, совместимого с v1.2.
SOAP с HTTP POST
В следующем примере показано использование сообщения SOAP в операции HTTP POST, которая отправляет сообщение на сервер. Он показывает пространства имен для определения схемы конверта и для определения схемы правил кодирования. Ссылка OrderEntry в заголовке HTTP — это имя программы, которая будет вызываться на веб-сайте tutorialspoint.com.
ПРИМЕЧАНИЕ. — Привязка HTTP указывает местоположение службы.
SOAP — заголовок
Необязательный элемент Header предлагает гибкую структуру для указания дополнительных требований уровня приложения. Например, элемент Header может использоваться для указания цифровой подписи для служб, защищенных паролем. Кроме того, его можно использовать для указания номера учетной записи для сервисов SOAP с оплатой за использование.
Указывает на заметку
Это необязательная часть сообщения SOAP.
Элементы заголовка могут встречаться несколько раз.
Заголовки предназначены для добавления новых функций и возможностей.
Заголовок SOAP содержит записи заголовка, определенные в пространстве имен.
Заголовок закодирован как первый непосредственный дочерний элемент конверта SOAP.
Когда определены несколько заголовков, все непосредственные дочерние элементы заголовка SOAP интерпретируются как блоки заголовка SOAP.
Это необязательная часть сообщения SOAP.
Элементы заголовка могут встречаться несколько раз.
Заголовки предназначены для добавления новых функций и возможностей.
Заголовок SOAP содержит записи заголовка, определенные в пространстве имен.
Заголовок закодирован как первый непосредственный дочерний элемент конверта SOAP.
Когда определены несколько заголовков, все непосредственные дочерние элементы заголовка SOAP интерпретируются как блоки заголовка SOAP.
Атрибуты заголовка SOAP
Заголовок SOAP может иметь следующие два атрибута:
Атрибут актера
Протокол SOAP определяет путь сообщения как список узлов службы SOAP. Каждый из этих промежуточных узлов может выполнить некоторую обработку и затем переслать сообщение следующему узлу в цепочке. Устанавливая атрибут Actor, клиент может указать получателя заголовка SOAP.
Атрибут MustUnderstand
Указывает, является ли элемент Header необязательным или обязательным. Если установлено значение true, получатель должен понимать и обрабатывать атрибут Header в соответствии с его определенной семантикой или возвращать ошибку.
В следующем примере показано, как использовать заголовок в сообщении SOAP.
МЫЛО — Тело
Тело SOAP является обязательным элементом, который содержит определяемые приложением данные XML, которыми обмениваются в сообщении SOAP. Тело должно содержаться в конверте и должно следовать всем заголовкам, которые могут быть определены для сообщения.
Тело определяется как дочерний элемент оболочки, а семантика для тела определяется в связанной схеме SOAP.
Тело содержит обязательную информацию, предназначенную для конечного получателя сообщения. Например —
В приведенном выше примере запрашивается расценка компьютерных комплектов. Обратите внимание, что элементы m: GetQuotation и Item выше являются специфичными для приложения элементами. Они не являются частью стандарта SOAP.
Вот ответ на вышеуказанный запрос —
Обычно приложение также определяет схему, содержащую семантику, связанную с элементами запроса и ответа.
МЫЛО — Неисправность
Если во время обработки возникает ошибка, ответ на сообщение SOAP является элементом ошибки SOAP в теле сообщения, и ошибка возвращается отправителю сообщения SOAP.
Механизм сбоя SOAP возвращает конкретную информацию об ошибке, включая предопределенный код, описание и адрес процессора SOAP, который сгенерировал сбой.
Указывает на заметку
Сообщение SOAP может содержать только один блок отказа.
Ошибка является необязательной частью сообщения SOAP.
Для привязки HTTP успешный ответ связан с диапазоном кодов состояния от 200 до 299.
Ошибка SOAP связана с диапазоном кодов состояния от 500 до 599.
Сообщение SOAP может содержать только один блок отказа.
Ошибка является необязательной частью сообщения SOAP.
Для привязки HTTP успешный ответ связан с диапазоном кодов состояния от 200 до 299.
Ошибка SOAP связана с диапазоном кодов состояния от 500 до 599.
Подэлементы неисправности
Ошибка SOAP имеет следующие подэлементы —