SOAP ( Простий протокол доступу до об’єктів ) і REST ( передача стану представлення ) - прекрасні на своєму шляху. Тож я їх не порівнюю. Натомість я намагаюся зобразити зображення, коли я вважав за краще використовувати REST та коли SOAP.
Що таке корисне навантаження?
Коли дані надсилаються через Інтернет, кожна передана одиниця включає як інформацію заголовка, так і фактичні дані, що надсилаються. Заголовок ідентифікує джерело та призначення пакету, а фактичні дані називають корисним навантаженням . Загалом корисна навантаження - це дані, які передаються від імені програми, та дані, отримані системою призначення.
Зараз, наприклад, я маю надіслати Telegram, і всі ми знаємо, що вартість телеграми буде залежати від деяких слів.
Тож скажіть мені серед наведених нижче цих двох повідомлень, яке з них дешевше надіслати?
<name>Arin</name>
або
"name": "Arin"
Я знаю, що ваша відповідь буде другою, хоча обидва, що представляють одне і те ж повідомлення, друге, дешевше щодо вартості.
Тому я намагаюся сказати, що надсилання даних по мережі у форматі JSON дешевше, ніж надсилання даних у форматі XML щодо корисної навантаження .
Ось перша перевага або переваги REST над SOAP . SOAP підтримує лише XML, але REST підтримує різний формат, наприклад текст, JSON, XML тощо.
Тепер SOAP підтримує єдиний XML, але він також має свої переваги.
Дійсно! Як?
SOAP покладається на XML трьома способами Envelope - який визначає, що є в повідомленні, і як його обробити.
Набір правил кодування для типів даних і нарешті макет процедури зібрав виклики та відповіді.
Цей конверт надсилається через транспорт (HTTP / HTTPS), і виконується RPC (віддалений виклик процедури), і конверт повертається з інформацією в документі, відформатованому XML.
Важливим моментом є те, що однією з переваг SOAP є використання «загального» транспорту, але REST використовує HTTP / HTTPS . SOAP може використовувати майже будь-який транспорт для надсилання запиту, але REST не може. Отже, тут ми отримали перевагу використання SOAP.
Як я вже згадував у вищевказаному пункті "REST використовує HTTP / HTTPS" , тож заглибимось у ці слова.
Коли ми говоримо про REST через HTTP, всі заходи безпеки, що застосовуються HTTP, успадковуються, і це відомо як безпека рівня транспорту, і він захищає повідомлення лише тоді, коли він знаходиться всередині проводу, але як тільки ви доставили його з іншого боку, ви не знаєте скільки етапів доведеться пройти, перш ніж досягти реальної точки, де дані будуть оброблятися. І звичайно, всі ці етапи могли використовувати щось інше, ніж HTTP. Тож відпочинок не безпечніший повністю, правда?
Але SOAP підтримує SSL так само, як і REST, він також підтримує WS-Security, що додає деякі функції безпеки підприємства. WS-Security пропонує захист від створення повідомлення до його споживання . Таким чином, для безпеки транспортного рівня незалежно від того, що ми знайшли щілину, яку можна запобігти за допомогою WS-Security.
Крім того, оскільки REST обмежений протоколом HTTP, тому його підтримка транзакцій не сумісна з ACID, а також не може забезпечити двофазну комісію між розподіленими транснаціональними ресурсами.
Але SOAP має всебічну підтримку як управління транзакціями на основі ACID для короткочасних транзакцій, так і управління транзакціями на основі компенсацій для довгострокових транзакцій. Він також підтримує двофазну комісію для розподілених ресурсів .
Я не роблю жодного висновку, але я віддаю перевагу веб-сервісу на основі SOAP, тоді як безпека, транзакції тощо є основними проблемами.
Ось "Підручник Java EE 6", де вони сказали, що RESTful дизайн може бути доречним, коли будуть виконані наступні умови . Гляньте.
Сподіваюся, вам сподобалось читати мою відповідь.
