Чи може хтось пояснити, що таке REST і що таке SOAP у звичайній англійській мові? А як працюють веб-сервіси?

Просте пояснення щодо SOAP та REST

SOAP - "Простий протокол доступу до об'єктів"

SOAP - це метод передачі повідомлень або невеликої кількості інформації через Інтернет. SOAP-повідомлення відформатовані в XML і зазвичай надсилаються за допомогою HTTP (протокол передачі гіпертексту).

Відпочинок - представницький державний трансфер

Відпочинок - це простий спосіб надсилання та отримання даних між клієнтом і сервером, і він не має визначених дуже багатьох стандартів. Ви можете надсилати та отримувати дані у вигляді JSON, XML або навіть простого тексту. Він легкий за вагою порівняно з SOAP.

Обидва методи використовуються багатьма великими гравцями. Це питання переваги. Моя перевага - REST, оскільки це простіше у використанні та розумінні.

Простий протокол доступу до об’єктів (SOAP):

• SOAP будує протокол XML поверх HTTP або іноді TCP / IP.
• SOAP описує функції та типи даних.
• SOAP є наступником XML-RPC і дуже схожий, але описує стандартний спосіб спілкування.
• Декілька мов програмування мають вбудовану підтримку SOAP, ти зазвичай подаєш її URL-адресу веб-служби, і ти можеш викликати її функції веб-сервісу без необхідності конкретного коду.
• Бінарні дані, що надсилаються, повинні спочатку кодуватися у такий формат, як закодований base64.
• Має декілька протоколів та технологій, що стосуються цього: WSDL, XSD, SOAP, WS-Addressing

Представницький державний трансфер (REST):

• REST не повинен бути над HTTP, але більшість моїх нижче пунктів матимуть ухил HTTP.
• REST дуже легкий, він говорить, почекайте хвилину, нам не потрібна вся ця складність, яку створив SOAP.
• Зазвичай використовує звичайні методи HTTP замість великого формату XML, що описує все. Наприклад, для отримання ресурсу, який ви використовуєте HTTP GET, для розміщення ресурсу на сервері, який ви використовуєте HTTP PUT. Для видалення ресурсу на сервері ви використовуєте HTTP DELETE.
• REST дуже простий, оскільки використовує методи HTTP GET, POST та PUT для оновлення ресурсів на сервері.
• REST зазвичай найкраще використовувати з ресурсно орієнтованою архітектурою (ROA). У такому режимі мислення все є ресурсом, і ви би працювали на цих ресурсах.
• Поки у вашій мові програмування є бібліотека HTTP, і це робиться в більшості випадків, ви можете дуже просто споживати протокол REST HTTP.
• Бінарні дані або двійкові ресурси можна просто доставити за їх запитом.

Існує нескінченні дебати на REST проти SOAP в Google .

Моя улюблена ця . Оновлення 27 листопада 2013 р. Здається, що веб-сайт Пола Прескода відключився в автономному режимі, і ця стаття більше недоступна, проте копії можна знайти на машині Wayback або у форматі PDF на CiteSeerX .

ВІДПОВІДНИЙ

Я розумію, що основна ідея REST надзвичайно проста. Ми використовуємо веб-браузери протягом багатьох років, і ми бачили, наскільки прості, гнучкі, ефективні тощо веб-сайти. HTML-сайти використовують гіперпосилання та форми як основний засіб взаємодії з користувачем. Їх головна мета - дозволити нам, клієнтам, знати лише ті посилання, якими ми можемо користуватися в поточному стані . І REST просто говорить: "чому б не використовувати ті самі принципи, щоб керувати комп'ютером, а не людськими клієнтами через наше додаток?" Поєднайте це з потужністю інфраструктури WWW, і ви отримаєте вбивчий інструмент для створення чудових розподілених додатків.

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

Досить дивно, що всі відповіді, схоже, зосереджені або на форматі повідомлення, або на використанні HTTP дієслів. Насправді формат повідомлення зовсім не має значення, REST може використовувати будь-який, за умови, що розробник служби його документує. Дієслова HTTP роблять сервіс лише послугою CRUD, але ще не RESTful. Що насправді перетворює послугу в REST-послугу - це гіперпосилання (так само гіпермедіа-керування), вбудовані у відповіді сервера разом із даними, і їх кількість повинна бути достатньою для того, щоб будь-який клієнт обрав наступну дію з цих посилань.

На жаль, досить складно знайти правильну інформацію про REST в Інтернеті, за винятком тези тези Роя Філдінга . (Він той, хто отримав REST). Я рекомендую книгу "REST in Practice", оскільки вона дає вичерпний покроковий посібник про те, як розвиватися від SOAP до REST.

Мило

Це одна з можливих форм архітектури стилю RPC (віддалений виклик процедури). По суті, це просто технологія, яка дозволяє клієнтам викликати методи сервера через межі обслуговування (мережу, процеси тощо) так, ніби вони викликали локальні методи. Звичайно, це насправді відрізняється від виклику місцевих методів швидкістю, надійністю тощо, але ідея така проста.

Порівняно

Деталі, такі як транспортні протоколи, формати повідомлень, xsd, wsdl тощо, не мають значення при порівнянні будь-якої форми RPC з REST. Основна відмінність полягає в тому, що служба RPC переосмислює велосипед, розробивши власний протокол програми в API RPC із семантикою, яку він знає лише він. Тому всі клієнти повинні розуміти цей протокол перед тим, як скористатися послугою, і жодна загальна інфраструктура, як кеші, не може бути побудована через власну семантику всіх запитів. Крім того, API RPC не передбачає, які дії дозволені в поточному стані, це повинно випливати з додаткової документації. З іншого боку, REST передбачає використання однакових інтерфейсів, що дозволяють різним клієнтам розуміти семантику API, а також засоби управління (посилання) гіпермедіа, щоб виділити доступні варіанти в кожному штаті. Таким чином,

Певним чином, SOAP (як і будь-який інший RPC) - це спроба тунелю через службову межу, що розглядає з'єднувальний носій як чорний ящик, здатний передавати повідомлення лише. REST - це рішення визнати, що Інтернет є величезною розповсюдженою інформаційною системою, прийняти світ таким, яким він є, і навчитися опановувати його, а не боротися з ним.

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

Оновлення

Мій досвід несподівано показав, що розвиток REST складніше, ніж SOAP. Принаймні для .NET. Хоча існують чудові рамки, такі як веб-API ASP.NET, немає інструментів, які б автоматично генерували проксі-клієнт. Нічого подібного до "Додати посилання на веб-службу" або "Додати посилання на службу WCF". Треба вручну написати весь код запиту на серіалізацію та обслуговування. А людина, це дуже багато кодового коду. Я думаю, що для розробки REST потрібне щось подібне до WSDL та впровадження інструментарію для кожної платформи розробки. Насправді, здається, що це добре: WADL або WSDL 2.0 , але жоден із стандартів, здається, не підтримується добре.

Оновлення (січень 2016 р.)

Виявляється, зараз існує широкий спектр інструментів для визначення API REST. Мої особисті переваги в даний час RAML .

Як працюють веб-сервіси

Ну, це занадто широке запитання, адже це залежить від архітектури та технології, що використовується в конкретному веб-сервісі. Але в цілому веб-сервіс - це просто програма у Мережі, яка може приймати запити клієнтів та повертати відповіді. Він доступний для Інтернету, таким чином, це веб- сервіс, і він зазвичай доступний 24/7, тому це послуга . Звичайно, це вирішує певну проблему (інакше чому б хтось коли-небудь користувався веб-сервісом) для своїх клієнтів.

Це найпростіше пояснення, яке ви коли-небудь знайдете.

У цій статті йдеться про розповідь чоловіка до дружини, де чоловік пояснює дружині про REST, чисто кажучи. Обов’язково читайте!

як-я-пояснив-відпочинок-дружині (оригінальне посилання)
як-я-пояснив-відпочинок-дружині (робоча посилання 2013-07-19)

SOAP - Простий протокол доступу до об’єктів - це протокол !

REST - Представницький державний трансфер - це архітектурний стиль !

SOAP являє собою XML-протокол, який використовується для передачі повідомлень, як правило, через HTTP

RESTі SOAP, мабуть, не є взаємовиключними. RESTful архітектура може використовувати HTTPабо SOAPінший протокол зв'язку. RESTоптимізовано для Інтернету і, таким чином, HTTPє ідеальним вибором. HTTPтакож є єдиним протоколом, про який йдеться в роботі Роя Філдінга.

Хоча REST і SOAP явно дуже різні, питання не висвітлює той факт, що RESTіHTTP часто використовуються в тандемі. В першу чергу це пов'язано з простотою HTTP та його дуже природним відображенням на принципах RESTful.

Основні принципи REST

Зв'язок клієнт-сервер

Клієнт-серверні архітектури мають дуже чітке розділення проблем. Усі програми, побудовані в стилі RESTful, також повинні бути клієнт-сервером у принципі.

Без громадянства

Кожен запит клієнта до сервера вимагає, щоб його стан був повністю представлений. Сервер повинен бути в змозі повністю зрозуміти запит клієнта без використання будь-якого контексту сервера або стану сеансу сервера. Звідси випливає, що весь стан повинен зберігатися у клієнта. Ми розглянемо представництво без громадянства детальніше пізніше.

Кешований

Обмеження кеш-пам'яті можуть бути використані, таким чином, дозволяючи дані відповіді бути позначені як кешовані або не кешовані. Будь-які дані, позначені як кешовані, можуть бути повторно використані як відповідь на той же наступний запит.

Уніфікований інтерфейс

Усі компоненти повинні взаємодіяти через єдиний єдиний інтерфейс. Оскільки взаємодія всіх компонентів відбувається через цей інтерфейс, взаємодія з різними службами дуже проста. Інтерфейс такий же! Це також означає, що зміни в реалізації можуть бути здійснені поодиноко. Такі зміни не вплинуть на взаємодію основних компонентів, оскільки єдиний інтерфейс завжди не змінюється. Одним недоліком є ​​те, що ви застрягли в інтерфейсі. Якщо оптимізація може бути надана певній службі шляхом зміни інтерфейсу, вам не пощастило, оскільки REST забороняє це. З іншого боку, REST оптимізовано для Інтернету, отже, неймовірна популярність REST через HTTP!

Вищезазначені поняття представляють визначальні характеристики REST та відрізняють архітектуру REST від інших архітектур, таких як веб-сервіси. Корисно зауважити, що служба REST - це веб-служба, але веб-служба не обов'язково є послугою REST.

Дивіться цю публікацію в блозі про принципи дизайну REST для отримання більш детальної інформації про REST та вищезазначені кулі.

Мені подобається відповідь Брайана Р. Бонді. Я просто хотів додати, що Вікіпедія дає чіткий опис REST . Стаття відрізняє його від SOAP.

REST - це обмін державною інформацією, який здійснюється максимально просто.

SOAP - протокол повідомлень, що використовує XML.

Однією з головних причин того, що багато людей перейшли від SOAP до REST, є те, що стандарти WS- * (звані WS splat), пов'язані з веб-службами на основі SOAP, надзвичайно складні. Переглянути технічні характеристики див. У wikipedia . Кожна з цих специфікацій дуже складна.

EDIT: чомусь посилання відображаються неправильно. REST = http://en.wikipedia.org/wiki/REST

WS- * = http://en.wikipedia.org/wiki/WS- *

Як веб-сервіси SOAP, так і веб-сервіси REST можуть також використовувати протокол HTTP та інші протоколи (лише згадати SOAP може бути базовим протоколом REST). Я буду говорити лише про протокол HTTP, пов’язаний з SOAP та REST, оскільки це найчастіше їх використання.

Мило

SOAP ("простий" протокол доступу до об'єктів) - це протокол (і стандарт W3C ). Він визначає, як створювати, надсилати та обробляти SOAP-повідомлення.

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

• SOAP-повідомлення пересуваються як повідомлення HTTP із підтипом SOAP + XML MIME. Ці повідомлення HTTP можуть бути багаточастинними, тому необов'язково ми можемо приєднувати файли до SOAP-повідомлень.

• Очевидно, що ми використовуємо архітектуру клієнт-сервер, тому клієнти SOAP надсилають запити до веб-секторів SOAP, а служби надсилають відповіді клієнтам. Більшість веб-сервісів використовують WSDL-файл для опису послуги. Файл WSDL містить схему XML (далі XSD) даних, які ми хочемо надіслати, та прив'язку WSDL, яка визначає, як веб-сервіс пов'язаний з протоколом HTTP. Існує два стилі прив’язки: RPC та документ. За стилем RPC, що зв'язує тіло SOAP, міститься подання операційного виклику з параметрами (HTTP запити) або значеннями повернення (HTTP-відповідь). Параметри та значення повернення підтверджені щодо XSD. За стилем документа, що пов'язує тіло SOAP, міститься документ XML, який підтверджений щодо XSD. Я думаю, що стиль прив’язки документів краще підходить для систем, заснованих на подіях, але я ніколи не використовував цей стиль прив'язки. Стиль прив'язки RPC є більш поширеним, тому більшість людей використовують SOAP для цілей XML / RPC в розподілених додатках. Веб-сервіси зазвичай знаходять один одного, запитуючи сервер UDDI . Сервери UDDI - це регістри, які зберігають розташування веб-сервісів.

SOAP RPC

Отже, на мій погляд, найпоширеніший веб-сервіс SOAP використовує стиль прив’язки RPC та стиль буквального кодування, і він має такі властивості:

• Він відображає URL-адреси для операцій.
• Він надсилає повідомлення з підтипом SOAP + XML MIME.
• Він може мати сховище сеансів на стороні сервера, обмежень щодо цього немає.
• Драйвери клієнта SOAP використовують файл WSDL сервісу для перетворення операцій RPC у методи. Клієнтська програма спілкується з веб-сервісом SOAP, викликаючи ці методи. Таким чином, більшість клієнтів SOAP розбиваються на зміни інтерфейсу (в результаті назви методів та / або зміни параметрів).
• Можна записати клієнтів SOAP, які не будуть порушені за допомогою зміни інтерфейсу за допомогою RDF та пошуку операцій за семантикою, але семантична веб-служба дуже рідкісна, і вони не обов'язково мають клієнта, що не працює (я думаю).

ВІДПОВІДНИЙ

REST (передавальний стан передачі) - це стиль архітектури, який описаний у дисертації Роя Філдінга. Це не стосується протоколів, як це робить SOAP. Він починається зі стилю нульової архітектури, що не має обмежень, і визначає обмеження архітектури REST по черзі. Люди використовують термін RESTful для веб-служб, які відповідають усім обмеженням REST, але, згідно з Роєм Філдінгом, таких речей, як рівні REST, немає . Коли веб-сервіс не відповідає кожному обмеженню REST, це не є REST веб-сервісом.

Обмеження REST

• Клієнт - архітектура сервера - я думаю, що ця частина знайома всім. Клієнти REST спілкуються з веб-сервісами REST, веб-сервіси підтримують загальні дані - стан ресурсів далі - і обслуговують їх клієнтів.
• Без громадянства - частина абревіатури "передача держави": REST. Клієнти підтримують стан клієнта (сеанс / стан програми), тому служби не повинні мати сховища сеансу. Клієнти передають відповідну частину стану клієнта за кожним запитом до служб, які відповідають відповідній частині стану ресурсу (підтримується ними). Тому запити не мають контексту, вони завжди містять необхідну інформацію для їх обробки. Наприклад, за допомогою HTTP basic auth ім'я користувача та пароль зберігаються клієнтом, і він надсилає їх із кожним запитом, тому автентифікація відбувається за кожним запитом. Це дуже відрізняється від звичайних веб-застосунків, коли автентифікація відбувається лише за допомогою входу. Ми можемо використовувати будь-який механізм зберігання даних на стороні клієнта, як вбудована пам'ять (javascript), файли cookie, localStorage тощо. щоб зберегти деякі частини стану клієнта, якщо ми хочемо. Причина обмеження безгромадянства полягає в тому, що сервер добре масштабує - навіть дуже велике навантаження (мільйони користувачів) - коли йому не потрібно підтримувати сеанс кожного окремого клієнта.
• Кеш - Відповідь повинна містити інформацію про неї, може кешуватися клієнтом чи ні. Це ще більше покращує масштабованість.

• Уніфікований інтерфейс

  • Ідентифікація ресурсів - REST-ресурс такий самий, як ресурс RDF . За словами Філдінга, якщо ви можете щось назвати, то це може бути ресурс, наприклад: "поточна погода в районі" може бути ресурсом, або "ваш мобільний телефон" може бути ресурсом, або "конкретний веб-документ" може бути ресурс. Для ідентифікації ресурсу можна використовувати ідентифікатори ресурсів: URL-адреси та URN (наприклад, номер ISBN у книгах ). Один ідентифікатор повинен належати лише певному ресурсу, але на одному ресурсі може бути багато ідентифікаторів, які ми часто використовуємо, наприклад, шляхом пагінації з такими URL-адресами https://example.com/api/v1/users?offset=50&count=25. URL-адреси є деякі технічні характеристики, наприклад, URL-адреси з однаковими патчами, але різні запити не є ідентичними, або частина шляху повинна містити ієрархічні дані URL-адреси, а частина запиту повинна містити неієрархічні дані. Це основи створення URL-адрес за допомогою REST. Btw. структура URL має значення лише для розробників сервісу, справжній клієнт REST не стосується цього. Ще одне часто задаване питання - це версія API, яка є легкою, оскільки, згідно з Філдінгом, єдиною постійною річчю за ресурсом є семантика. Якщо семантика зміниться, ви можете додати номер нової версії. Ви можете використовувати класичну версію на 3 номери та додати лише головне число до URL-адрес (https://example.com/api/v1/). Таким чином, завдяки зворотно сумісним змінам нічого не відбудеться, при невідповідних сумісних змінах у вас з'явиться невідповідна сумісна семантика з новим коренем API https://example.com/api/v2/. Тож старі клієнти не зламаються, тому що вони можуть використовувати https://example.com/api/v1/стару семантику.
  • Маніпулювання ресурсами через представлення - Ви можете маніпулювати даними, що стосуються ресурсів (стан ресурсу), надіславши призначене представлення ресурсів разом із методом HTTP та ідентифікатором ресурсу - службі REST. Наприклад, якщо ви хочете перейменувати користувача після одруження, ви можете надіслати PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"}запит, де {name: "Mrs Smith"}є JSON-представлення призначеного стану ресурсу, іншими словами: нове ім'я. Це трапляється, навпаки, служба надсилає клієнтам представлення ресурсів з метою зміни їх стану. Наприклад, якщо ми хочемо прочитати нове ім'я, ми можемо надіслати GET https://example.com/api/v1/users/1?fields="name"запит на пошук, в результаті якого з'явиться a200 ok, {name: "Mrs Smith"}відповідь. Тож ми можемо використовувати це представлення для зміни стану клієнта, наприклад, можемо відобразити "Ласкаво просимо на нашу сторінку місіс Сміт!" повідомлення. У ресурсу може бути багато представлень, залежно від ідентифікатора ресурсу (URL) або acceptзаголовка, який ми надіслали із запитом. Наприклад, ми можемо надіслати зображення місіс Сміт (напевно, не оголеного), якщо image/jpegбуде запитано.
  • Самоописові повідомлення - Повідомлення повинні містити інформацію про те, як їх обробити. Наприклад метод URI та HTTP, заголовок типу вмісту, заголовки кешу, RDF, який описує значення даних тощо. Важливо використовувати стандартні методи. Важливо знати специфікацію методів HTTP. Наприклад, GET означає отримання інформації, ідентифікованої URL-адресою запиту, DELETE означає прохання сервера видалити ресурс, ідентифікований вказаною URL-адресою і так далі ... Коди статусу HTTP також мають специфікацію , наприклад 200 означає успіх, 201 означає створено новий ресурс, 404 означає, що запитуваний ресурс не знайдено на сервері тощо. Використання існуючих стандартів є важливою частиною REST.

  • Гіпермедіа як двигун стану застосування (HATEOAS далі) - Hypermedia - це тип носія, який може містити гіперпосилання. В Інтернеті ми переходимо до посилань - описаних у форматі гіпермедіа (зазвичай HTML) - для досягнення мети, замість того, щоб вводити URL-адреси на панелі адрес. REST слід за тією ж концепцією, представлення, надіслані службою, можуть містити гіперпосилання. Ми використовуємо ці гіперпосилання для надсилання запитів до служби. За допомогою відповіді ми отримуємо дані (і, напевно, більше посилань), які ми можемо використовувати для створення нового стану клієнта тощо. Отже, саме тому гіпермедіа є двигуном стану програми (стан клієнта). Вам, напевно, цікаво, як клієнти розпізнають і переглядають гіперпосилання? Для людей це досить просто, ми читаємо заголовок посилання, можливо, заповнюємо поля введення, а після цього лише одним клацанням миші.JSON-LD з Hydra ) або зі специфічними рішеннями для гіпермедіа (наприклад, зв'язки зв’язків IANA та типи MIME, специфічні для виробника , HAL + JSON ). Є багато машиночитаних форматів гіпермедіа XML та JSON , лише короткий їх список:

    • XHTML
    • ATOM + XML
    • RDF + XML
    • HAL + XML
    • HAL + JSON
    • JSON-LD
    • RDF + JSON
    • Сирена
    • Колекція + JSON

    Іноді важко вибрати ...

• Багатошарова система - Ми можемо використовувати декілька шарів між клієнтами та службами. Жоден з них не повинен знати про всі ці додаткові шари, просто про шар біля нього. Ці шари можуть покращити масштабованість, застосувавши кеші та балансуючи навантаження, або вони можуть застосовувати політику безпеки.
• Код на вимогу - ми можемо надіслати зворотний код, який розширює функціональність клієнта, наприклад, код JavaScript у браузері. Це єдине необов'язкове обмеження REST.

REST webservice - розбіжність у веб-сервісі SOAP RPC

Отже веб-сервіс REST сильно відрізняється від веб-сервісу SOAP (зі стилем прив’язки RPC та стилем буквального кодування)

• Він визначає єдиний інтерфейс (intead протоколу).
• Він відображає URL-адреси на ресурси (а не операції).
• Він надсилає повідомлення будь-яких типів MIME (замість SOAP + XML).
• Він має зв'язок без стану, і тому він не може зберігати сеанс на сервері. (SOAP не обмежує цього)
• Він обслуговує гіпермедіа, і клієнти використовують посилання, що містяться в цій гіпермедіа, щоб запитувати послугу. (SOAP RPC використовує операційні прив’язки, описані у файлі WSDL)
• Він не розбивається на зміни URL-адреси лише на зміну семантики. (Клієнти SOAP RPC без використання розбиття семантики RDF на зміну файлу WSDL.)
• Він масштабується краще, ніж веб-сервіс SOAP через поведінку без громадянства.

і так далі...

Веб-служба SOAP RPC не відповідає всім обмеженням REST:

• архітектура клієнт-сервер - завжди
• без громадянства - можливо
• кеш - можливо
• рівномірний інтерфейс - ніколи
• багатошарова система - ніколи
• код на вимогу (необов’язково) - можливий

Ну я розпочну з другого питання: Що таке веб-сервіси? , з очевидних причин.

Веб-сервіси, по суті, є частинами логіки (яку ви можете смутно називати методом), яка розкриває певну функціональність або дані. Клієнт, який реалізує (технічно кажучи, споживає це слово), просто повинен знати, які параметри (и) буде прийнятий методом і тип даних, який він збирається повернути (якщо він взагалі це робить).

Наступне посилання розповідає все про REST & SOAP надзвичайно чітко.

REST vs SOAP

Якщо ви також хочете знати, коли вибрати що (REST або SOAP), тим більше причин пройти це!

SOAP та REST посилаються на способи, коли різні системи можуть спілкуватися між собою.

REST робить це за допомогою методів, що нагадують зв'язок вашого веб-браузера з веб-серверами: використання GET для запиту веб-сторінки, розміщення в полях форм тощо.

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

Я думаю, що це так просто, як я можу це пояснити. Будь ласка, будь-хто бажає виправити мене або додати до цього.

SOAP - це формат повідомлень, який використовується відключеними системами (наприклад, через Інтернет) для обміну інформацією / даними. Це стосується XML-повідомлень, які рухаються вперед і назад.

Веб-сервіси передають або отримують повідомлення SOAP. Вони працюють по-різному, залежно від того, якою мовою вони написані.

Проблема SOAP полягає в тому, що він суперечить ідеалам, що стоять за стеком HTTP. Будь-яке посереднє програмне забезпечення повинно бути в змозі працювати з HTTP-запитами, не розуміючи змісту запиту чи відповіді, але, наприклад, звичайний сервер кешування HTTP не працюватиме із запитами SOAP, не знаючи лише, які частини вмісту SOAP мають значення для кешування. SOAP просто використовує HTTP як обгортку для власного протоколу зв'язку, як проксі.

REST - це стиль архітектури для проектування мережевих додатків. Ідея полягає в тому, що замість використання складних механізмів, таких як CORBA, RPC або SOAP для з'єднання між машинами, для здійснення дзвінків між машинами використовується простий HTTP.

SOAP - "Простий протокол доступу до об'єктів"

SOAP - це незначна передача повідомлень або невелика кількість інформації через Інтернет. SOAP- повідомлення відформатовані в XML і зазвичай надсилаються керуючими HTTP .

REST - "Представницький державний трансфер"

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

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

ми все ще можемо пов'язувати SOAP з віддаленими викликами процедур на основі XML, але технологія веб-служб на базі SOAP перетворилася на гнучку та потужну модель обміну повідомленнями.

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

Контракти між системами спільно називаються метаданими і містять описи послуг, підтримувані шаблони обміну повідомленнями та політику, що регулює якості обслуговування (послуга може знадобитися зашифрована, надійно доставлена ​​тощо). Опис послуги, у свою чергу, є детальним специфікація даних (документів із повідомленнями), які надсилаються та отримуються системою. Документи описуються за допомогою мови опису XML на зразок визначення XML Schema. Поки всі системи виконують свої опубліковані договори, вони можуть взаємодіяти, а зміни у внутрішніх системах ніколи не впливають на будь-які інші. Кожна система несе відповідальність за переклад власних внутрішніх реалізацій в договори та з них

REST - Представницький державний трансфер. Фізичний протокол - HTTP. В основному REST полягає в тому, що всі окремі ресурси в Інтернеті, які однозначно ідентифікуються за URL-адресою. Усі операції, які можуть бути виконані на цих ресурсах, можна описати обмеженим набором дієслів («дієслова CRUD»), які в свою чергу відображають на HTTP дієслова.

REST набагато менше "важкої ваги", ніж SOAP.

Робота веб-сервісу