SOAP API

Наприкінці 1990-х років протокол SOAP був розроблений для обміну даними у форматі XML між клієнтом та сервером. Давайте розберемося, що таке SOAP API зараз і в яких випадках його використовувати. Поговоримо про недоліки, і чому йому на п'яти настає REST API.

SOAP (Simple Object Access Protocol) – це протокол обміну повідомленнями між комп'ютерними системами.

SOAP API (Application Programming Interface) - це інтерфейс, який дозволяє взаємодіяти з віддаленими сервісами або програмами з використанням SOAP протоколу. SOAP API базується на використанні XML для опису структури та вмісту повідомлень. Повідомлення в SOAP API є XML-документи, які містять дані та виклики методів для віддаленого виконання операцій.

Базові поняття SOAP API

Пакети. У SOAP API дані передаються у вигляді пакетів - це обгортки для інформації, що передається між клієнтом та сервером. Кожен пакет містить заголовок (header) та тіло (body). У заголовку можна вказати додаткові метадані, такі як інформацію про безпеку або версію протоколу. У тілі пакета знаходяться дані, які можуть бути представлені у вигляді XML-структури.

Правила кодування. SOAP API працює з XML для кодування даних. XML (eXtensible Markup Language) використовує теги та атрибути для опису структури даних. SOAP визначає набір правил, які визначають, як дані мають бути представлені у форматі XML. Наприклад, SOAP визначає правила для серіалізації об'єктів, передачі значень та обробки помилок.

Стилі взаємодії. SOAP API підтримує різні стилі взаємодії, які визначають, як клієнт та сервер обмінюються даними, наприклад:

• Стиль RPC. У RPC-стилі клієнт викликає віддалений метод сервера, передаючи йому параметри. Сервер виконує метод та повертає результат назад клієнту. Стиль RPC абстрагує виклики віддалених методів, роблячи їх схожими на виклики локальних методів.
• Document-style. У Document-стилі дані передаються як XML-документа. Замість виклику методів, клієнт та сервер обмінюються структурованими XML-даними. Document-style більш гнучкий і дозволяє передавати складні об'єкти та атрибути.

Модель даних SOAP

Модель даних SOAP визначає типи даних, які можуть бути передані і дозволяє визначати типи даних користувача та їх структуру.

Елементи моделі даних SOAP

Елементи XML: необхідні представлення даних у SOAP повідомленнях. Кожен елемент має ім'я та може містити інші елементи чи текстові дані.

Атрибути XML: використовуються для подання додаткової інформації про елемент. Вони мають ім'я та значення і можуть бути використані для передачі метаданих або керування обробкою даних.

Прості типи даних: рядки, числа, дати та логічні значення. Вони можуть бути використані для представлення простих значень у повідомленнях SOAP.

Складні типи даних: структури та масиви. Структури містять кілька елементів різних типів, а масиви кілька елементів одного типу.

Простір імен: існують для вирішення конфліктів імен елементів та типів даних. Простір імен дозволяє унікально ідентифікувати елементи та типи даних в рамках SOAP повідомлення.

Що може SOAP API

• Створювати структуровані повідомлення: за допомогою опису формату повідомлень у XML, який зрозумілий для більшості мов програмування та платформ
• Працювати з різними протоколами: такі як HTTP, HTTPS, SMTP, FTP.Це робить його гнучким і дозволяє інтегрувати системи, які використовують різні протоколи
• Підтримувати різні платформи та мови програмування: такі як Java, .NET, PHP. Це робить його доступним для широкого кола розробників і дозволяє створювати міжплатформні програми
• Розширювати функціональність: SOAP API дозволяє визначати власні типи даних користувача і має такі розширення, як WS-Security для забезпечення безпеки або WS-ReliableMessaging для забезпечення надійної доставки повідомлень.

Популярність та актуальність

SOAP API знайшов широке застосування в інтеграції між системами, особливо у великих підприємствах, де потрібен обмін даними між додатками та платформами. Також він використовується у веб-сервісах для надання API для зовнішніх розробників.

В останні роки популярність SOAP знизилася у зв'язку з розвитком більш легких і простих у використанні протоколів, таких як REST (Representational State Transfer). REST API став більш відомим через свою простоту, гнучкість та підтримку форматів даних, таких як JSON.

У результаті вибір між SOAP API та іншими протоколами залежить від конкретних вимог і контексту проекту.

Відмінності SOAP від ​​REST

Архітектура:

• REST використовує стандартні HTTP-методи, такі як GET, POST, PUT та DELETE
• SOAP працює з форматом XML для серіалізації даних та надає можливість обміну складними об'єктами та атрибутами.

Протокол передачі:

• REST базується на протоколі HTTP
• SOAP більш гнучкий у виборі протоколу передачі.

Формат даних:

• REST працює як із JSON, XML, так і з простим текстом.
• SOAP використовує XML для серіалізації та передачі даних.

Універсальність та простота використання:

• REST простий і гнучкий у використанні.
• SOAP надає багатий набір функцій та підтримує складні операції та транзакції. SOAP вимагає наявності Web Services Description Language (WSDL) для опису веб-служб.

Приклад SOAP API

Приклад REST API

GET /api/stocks/IBM HTTP/1.1 Host: example.com

У прикладі SOAP бачимо структуроване XML-повідомлення, у якому вказується операція GetStockPrice і параметр StockName зі значенням IBM.

У прикладі REST ми бачимо простий HTTP-запит GET, в якому вказується адреса ресурсу /api/stocks/IBM для отримання інформації про акцію IBM.

У яких випадках використовують SOAP API

• У інтеграції складних систем. 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 і назад.
• Один запит - одна відповідь: клієнт повинен надіслати запит та дочекатися відповіді від сервера, перш ніж продовжити виконання наступних операцій. Це може призвести до блокування клієнтської програми, якщо запит довго опрацьовується.
• Можливість порушення роботи клієнта при зміні опису веб-сервісу: зміна опису вимагатиме додаткових зусиль для узгодження змін між постачальником та споживачем сервісу.

Що таке 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, що містять повідомлення, що надсилається. Це є обов'язковим елементом.

Несправність — необов'язковий елемент несправності, який надає інформацію про помилки, що виникають під час обробки повідомлення.

Всі ці елементи оголошені у просторі стандартних імен для конверта SOAP — http://www.w3.org/2001/12/soap-envelope, а простір стандартних імен для кодування SOAP та типів даних — http://www.w3 .org / 2001/12 / мило-кодування

ПРИМІТКА. — Усі ці характеристики можуть бути змінені. Так що продовжуйте оновлювати себе найновішими специфікаціями, доступними на сайті W3.

Структура повідомлення SOAP

Наступний блок відображає загальну структуру повідомлення SOAP

xml version
=
"1.0"?>

xmlns:SOAP-ENV
=
"http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle
=
"http://www.w3.org/2001/12/soap-encoding">

. .


. .

. .

.

МИЛО - Конверт

Конверт SOAP вказує початок та кінець повідомлення, щоб одержувач знав, коли було отримано все повідомлення. Конверт SOAP вирішує проблему визначення того, коли ви отримали повідомлення та готові його обробити. Тому конверт SOAP це, по суті, механізм упаковки.

Вказує на замітку

• Кожне повідомлення SOAP має кореневий елемент Envelope.
• Конверт є обов'язковою частиною повідомлення SOAP.
• Кожен елемент Envelope повинен містити рівно один елемент Body.
• Якщо конверт містить елемент заголовка, він повинен містити не більше одного елемента і відображатись як перший дочірній елемент конверта перед тілом.
• Конверт змінюється під час зміни версій SOAP.
• Конверт SOAP вказується за допомогою префікса простору імен ENV та елементу Envelope.
• Необов'язкове кодування SOAP також вказується з використанням імені простору імен та необов'язкового елемента encodingStyle , який також може вказувати стиль кодування, відмінний від стилю SOAP.
• SOAP-процесор, сумісний з v1.1, створює помилку при отриманні повідомлення, що містить простір імен конверта v1.2.
• SOAP-процесор, сумісний із v1.2, генерує помилку VersionMismatch, якщо він отримує повідомлення, яке не включає простір імен конверта v1.2.

Кожне повідомлення SOAP має кореневий елемент Envelope.

Конверт є обов'язковою частиною повідомлення SOAP.

Кожен елемент Envelope повинен містити рівно один елемент Body.

Якщо конверт містить елемент заголовка, він повинен містити не більше одного елемента і відображатись як перший дочірній елемент конверта перед тілом.

Конверт змінюється під час зміни версій SOAP.

Конверт SOAP вказується за допомогою префікса простору імен ENV та елементу Envelope.

Необов'язкове кодування SOAP також вказується з використанням імені простору імен та необов'язкового елемента encodingStyle , який також може вказувати стиль кодування, відмінний від стилю SOAP.

SOAP-процесор, сумісний з v1.1, створює помилку при отриманні повідомлення, що містить простір імен конверта v1.2.

SOAP-процесор, сумісний із v1.2, генерує помилку VersionMismatch, якщо він отримує повідомлення, яке не включає простір імен конверта v1.2.

v1.2-сумісне повідомлення SOAP

Нижче наведено приклад повідомлення SOAP, сумісного з v1.2.

. Message information goes here .

SOAP з HTTP POST

У цьому прикладі показано використання повідомлення SOAP в операції HTTP POST, яка надсилає повідомлення на сервер. Він показує простору імен визначення схеми конверта й у визначення схеми правил кодування. Посилання OrderEntry у заголовку HTTP – це ім'я програми, яка буде викликатись на веб-сайті tutorialspoint.com.

POST /OrderEntry HTTP/1.1 Host: www.tutorialspoint.com Content-Type: application/soap; charset = "utf-8" Content-Length: nnnn  . Message information goes here .

ПРИМІТКА. — Прив'язка 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.

Ось відповідь на вищезгаданий запит

Зазвичай, додаток також визначає схему, що містить семантику, пов'язану з елементами запиту та відповіді.

Сервіс Quotation може бути реалізований з використанням EJB, що працює на сервері додатків; в цьому випадку процесор SOAP буде відповідати за відображення інформації тіла в якості параметрів і з реалізації EJB служби GetQuotationResponse . Процесор SOAP також може відображати інформацію тіла об'єкт .NET, об'єкт CORBA, програму COBOL тощо.

МИЛО - Несправність

Якщо під час обробки виникає помилка, відповідь на повідомлення SOAP є елементом помилки SOAP у тілі повідомлення та помилка повертається відправнику повідомлення SOAP.

Механізм збою SOAP повертає конкретну інформацію про помилку, включаючи наперед визначений код, опис та адресу процесора SOAP, який згенерував збій.

Вказує на замітку

• Повідомлення SOAP може містити лише один блок відмови.
• Помилка не є обов'язковою частиною повідомлення SOAP.
• Для прив'язки HTTP успішна відповідь пов'язана з діапазоном кодів стану від 200 до 299.
• Помилка SOAP пов'язана з діапазоном кодів стану від 500 до 599.

Повідомлення SOAP може містити лише один блок відмови.

Помилка не є обов'язковою частиною повідомлення SOAP.

Для прив'язки HTTP успішна відповідь пов'язана з діапазоном кодів стану від 200 до 299.

Помилка SOAP пов'язана з діапазоном кодів стану від 500 до 599.

Поделементи несправності

Помилка SOAP має такі поделементи

Це текстовий код, який використовується для позначення класу помилок. У наступній таблиці наведено перелік визначених кодів помилок.

Це текстове повідомлення, яке пояснює помилку.

Це текстовий рядок, який вказує на те, хто викликав помилку. Це корисно, якщо повідомлення SOAP проходить через кілька вузлів у дорозі повідомлення SOAP, і клієнт повинен знати, який вузол викликав помилку. Вузол, який не діє як кінцевий пункт призначення, повинен містити елемент faultActor .

Це елемент, який використовується для надсилання повідомлень про помилки програми. Елемент detail може містити дочірні елементи, які називають елементами detail.

Це текстовий код, який використовується для позначення класу помилок. У наступній таблиці наведено перелік визначених кодів помилок.

Це текстове повідомлення, яке пояснює помилку.

Це текстовий рядок, який вказує на те, хто викликав помилку. Це корисно, якщо повідомлення SOAP проходить через кілька вузлів у дорозі повідомлення SOAP, і клієнт повинен знати, який вузол викликав помилку. Вузол, який не діє як кінцевий пункт призначення, повинен містити елемент faultActor .

Це елемент, який використовується для надсилання повідомлень про помилки програми. Елемент detail може містити дочірні елементи, які називають елементами detail.

Коди помилок SOAP

Наведені нижче значення faultCode повинні використовуватися в елементі faultcode під час опису несправностей.

SOAP-ENV: VersionMismatch

Виявлено неприпустиме місце імен для елемента конверта SOAP.

SOAP-ENV: MustUnderstand

Безпосередній дочірній елемент елемента Header з атрибутом mustUnderstand, встановленим у «1», був зрозумілий.

Повідомлення було неправильно сформовано чи містило неправильну інформацію.

Виникла проблема із сервером, тому повідомлення не вдалося продовжити.

SOAP-ENV: VersionMismatch

Виявлено неприпустиме місце імен для елемента конверта SOAP.

SOAP-ENV: MustUnderstand

Безпосередній дочірній елемент елемента Header з атрибутом mustUnderstand, встановленим у «1», був зрозумілий.

Повідомлення було неправильно сформоване або містило неправильну інформацію.

Виникла проблема із сервером, тому повідомлення не вдалося продовжити.

Приклад помилки SOAP

Наступний код є прикладом несправності. Клієнт запросив метод з ім'ям ValidateCreditCard Але служба не підтримує такий метод. Це помилка запиту клієнта, і сервер повертає наступну відповідь SOAP —

SOAP-ENV:Client
Використовується для локального методу (ValidateCreditCard) в класі (examplesCreditCard) в /usr/local/ActivePerl-5.6/lib/site_perl/5.6.0/SOAP/Lite.pm line 1555.

SOAP — Кодування

SOAP включає вбудований набір правил для кодування типів даних. Це дозволяє SOAP вказувати конкретні типи даних, такі як цілі числа, числа з плаваючою комою, подвійні числа або масиви.

• Типи даних SOAP поділяються на дві широкі категорії - скалярні типи та складові типи.
• Скалярні типи містять одне значення, таке як прізвище, ціна або опис продукту.
• Складові типи містять кілька значень, таких як замовлення на купівлю або перелік котирувань акцій.
• Типи сполук далі поділяються на масиви та структури.
• Стиль кодування для повідомлення SOAP встановлюється через атрибут SOAP-ENV: encodingStyle .
• Для використання кодування SOAP 1.1 використовуйте значення http://schemas.xmlsoap.org/soap/encoding/
• Для використання кодування SOAP 1.2 використовуйте значення http://www.w3.org/2001/12/soap-encoding
• Остання специфікація SOAP приймає усі вбудовані типи, визначені XML-схемою. Тим не менш, SOAP підтримує свою власну угоду для визначення конструкцій, не стандартизованих XML-схемою, таких як масиви та посилання.

Типи даних SOAP поділяються на дві широкі категорії - скалярні типи та складові типи.

Скалярні типи містять одне значення, таке як прізвище, ціна або опис продукту.

Складові типи містять кілька значень, таких як замовлення на купівлю або перелік котирувань акцій.

Типи сполук далі поділяються на масиви та структури.

Стиль кодування для повідомлення SOAP встановлюється через атрибут SOAP-ENV: encodingStyle .

Для використання кодування SOAP 1.1 використовуйте значення http://schemas.xmlsoap.org/soap/encoding/

Для використання кодування SOAP 1.2 використовуйте значення http://www.w3.org/2001/12/soap-encoding

Остання специфікація SOAP приймає усі вбудовані типи, визначені XML-схемою. Тим не менш, SOAP підтримує свою власну угоду для визначення конструкцій, не стандартизованих XML-схемою, таких як масиви та посилання.

Скалярні типи

Для скалярних типів SOAP приймає всі прості типи, вказані в специфікації XML-схеми. Це включає рядки, числа з плаваючою комою, подвійні і цілі числа.

У наступній таблиці наведено основні прості типи, взяті з XML-схеми, частина 0 — підручник http://www.w3.org/TR/2000/WD-xmlschema-0-20000407/.

Наприклад, ось відповідь SOAP з подвійним типом даних

Типи з'єднань

Масиви SOAP мають дуже специфічний набір правил, які вимагають щоб ви вказали як тип елемента, так і розмір масиву. SOAP також підтримує багатовимірні масиви, але не всі реалізації SOAP підтримують багатовимірну функціональність.

Щоб створити масив, ви повинні вказати його як масив xsi: type . Масив також має включати атрибут arrayType . Цей атрибут необхідний для вказівки типу даних для елементів і вимірювань масиву, що містяться.

Наприклад, наступний атрибут задає масив із 10 подвійних значень.

arrayType = "xsd:double[10]"

На противагу цьому наступний атрибут задає двовимірний масив рядків:

arrayType = "xsd:string[5,5]"

Ось приклад відповіді SOAP з масивом подвійних значень:

Структури містять кілька значень, але кожен елемент вказаний унікальним елементом доступу. Наприклад, розглянемо елемент у каталозі продуктів. У цьому випадку структура може містити SKU продукту, назву продукту, опис та ціну. Ось як така структура буде представлена ​​у повідомленні SOAP:

Red Hat Linux
54.99
Red Hat Linux Operating System
A358185

ПРИМІТКА. — Будь ласка, подбайте про правильний відступ під час написання коду SOAP. Кожен елемент у структурі вказується з унікальним ім'ям доступу. Наприклад, вищенаведене повідомлення включає чотири елементи доступу - ім'я, ціна, опис і артикул. Кожен елемент може мати власний тип даних. Наприклад, ім'я вказується як рядок, а ціна вказується як подвійна.

МИЛО — Транспорт

SOAP не прив'язаний до жодного транспортного протоколу. SOAP може транспортуватися через SMTP, FTP, IBM MQSeries або Microsoft Message Queuing (MSMQ).

Специфікація SOAP містить подробиці лише з HTTP. HTTP залишається найпопулярнішим транспортним протоколом SOAP.

SOAP через HTTP

Логічно, що SOAP-запити надсилаються через HTTP-запит, а SOAP-відповіді повертаються у вмісті HTTP-відповіді. Хоча запити SOAP можна надсилати через HTTP GET, специфікація містить лише відомості про HTTP POST.

Крім того, як HTTP-запити, так і відповіді потрібні для встановлення типу контенту text/xml.

Специфікація SOAP вимагає, щоб клієнт надав заголовок SOAPAction, Проте фактичне значення заголовка SOAPAction залежить від реалізації сервера SOAP.

Наприклад, щоб отримати доступ до служби перекладу AltaVista BabelFish, розміщеної в XMethods, як заголовок SOAPAction необхідно вказати наступне.

urn:xmethodsBabelFish#BabelFish

Навіть якщо сервер не потребує повного заголовка SOAPAction, клієнт повинен вказати порожній рядок («») або нульове значення. Наприклад -

SOAPAction: "" SOAPAction:

Ось приклад запиту, надісланого через HTTP до служби перекладу XMethods Babelfish:

POST /perl/soaplite.cgi HTTP/1.0 Host: services.xmethods.com Content-Type: text/xml; charset = utf-8 Content-Length: 538 SOAPAction: "urn:xmethodsBabelFish#BabelFish"  

en_fr
Hello, world!

Зверніть увагу на тип вмісту та заголовок SOAPAction. Також зверніть увагу, що метод BabelFish потребує двох параметрів String. Режим перекладу en_fr перекладає з англійської на французьку.

Ось відповідь від XMethods

HTTP/1.1 200 OK Дата: Sat, 09 Jun 2001 15:01:55 GMT Server: Apache/1.3.14 (Unix) tomcat/1.0 PHP/4.0.1pl2 SOAPServer: SOAP::Lite/Perl/0.50 Cache-Control: s-maxage = 60, proxy-revalidate Content-Length: 539 Content-Type: text/xml  

Bonjour, monde!

Відповіді SOAP, що надсилаються через HTTP, повинні виконувати такі самі коди стану HTTP. Наприклад, код стану 200 OK вказує на успішну відповідь. Код стану 500 Internal Server Error вказує, що помилка сервера відбулася і що відповідь SOAP містить елемент Fault.

SOAP - Приклади

У наведеному нижче прикладі запит GetQuotation надсилається на сервер SOAP через HTTP. Запит має параметр QuotationName , і у відповіді буде повернено пропозицію.

Простір імен для функції визначається за адресою http://www.xyz.org/quotation.

POST /Quotation HTTP/1.0 Host: www.xyz.org Content-Type: text/xml; charset = utf-8 Content-Length: nnn  

MiscroSoft

Відповідна SOAP-відповідь виглядає так:

HTTP/1.0 200 OK Content-Type: text/xml; charset = utf-8 Content-Length: nnn  

Here is the quotation

SOAP - Стандарти

SOAP 1.1 був спочатку представлений W3C у травні 2000 року. Офіційними представниками були великі компанії, такі як Microsoft, IBM та Ariba, а також невеликі компанії, такі як UserLand Software та DevelopMentor.

У липні 2001 року робоча група протоколу XML випустила «робочий проект» SOAP 1.2. У рамках W3C цей документ офіційно знаходиться на стадії розробки, що означає, що документ, ймовірно, буде оновлюватися багато разів, перш ніж буде завершено.