Наскільки я бачу, для споживання SOAP потрібен стек SOAP, тому вашим клієнтам складніше споживати, тобто їм потрібно забезпечити наявність у них стека SOAP, який форматує дані POST та заголовки правильно, а потім поверне вам трохи структура даних, тоді як з REST ви просто робите HTTP GET-запит з аргументами в рядку запиту і отримуєте назад текст, який, напевно, є XML.
Отже, що дає додаткова накладність / складність SOAP, коли вам це потрібно і коли ви можете і чи не обійдетесь без цього?
Відповіді:
Я вже реалізував API REST і мені дуже сподобався. Загалом, коли ви реалізуєте REST через SOAP, ваш клієнт / сервер має більше ортогонального значення, тобто ви можете набагато вільніше змінювати сервер, не впливаючи на своїх клієнтів. Ця ортогональність обумовлена використанням більш абстрактного та вже чітко визначеного зв'язку через дієслова HTTP. Крім того, використання гіперпосилань, вбудованих у ваші відповіді REST, полегшує розширення та розширення вашого API відносно безболісно. Клієнти повинні дотримуватися цих вбудованих посилань, щоб дістатися до нових ресурсів, як, наприклад, людина переходитиме до посилань на веб-сторінці, щоб «отримати детальну інформацію» для отримання додаткової інформації.
З урахуванням сказаного, у мене були співробітники, які мені сказали, що вони повинні використовувати SOAP, і вони весь час скаржилися на це. Тому я трохи детальніше розібрався з двома.
Загалом, я виявив, що REST добре підходить для високорозподілених програм , коли у вас є сотні, тисячі або мільйони клієнтів . Одна з причин - вищезазначена ортогональність, інша - кешування, яке ви отримуєте безкоштовно, оскільки ви використовуєте HTTP.
SOAP може бути швидшим шляхом, коли вам потрібен менший API для клієнта або двох швидко, і ви не надто переживаєте про масштабованість. Можливо, вам також краще підійде, якщо у вас немає архітектури, структурованої навколо ресурсів , оскільки це може зайняти певний час, щоб реструктурувати додаток, щоб навіть можна було реалізувати REST.
Це може бути незначним моментом, але REST повністю базується на HTTP.
SOAP не вимагає HTTP, і ви можете безкоштовно використовувати будь-який транспорт.
Повідомлення SOAP можна маршрутизувати асинхронно та надійно, тоді як REST - це майже синхронна парадигма.
REST нічого не розповідає про те, як повинні виглядати дані, які ви надсилаєте та отримуєте. Існує WADL, але в основному ви покладаєтесь на правильність документації API. SOAP має цирк XML-технологій, щоб зробити опис даних менш схильним до помилок. WSDL, схема ...
Наприкінці дня REST в основному отримує файлову систему на базі HTTP. Якщо ваша система може вписатися в цю парадигму - то це може бути хорошим вибором.
Отже, що дає додаткова накладність / складність SOAP, коли вам це потрібно і коли ви можете і чи не обійдетесь без цього?
Найбільша різниця між ними полягає в тому, що REST, мабуть, без громадянства, де SOAP це не так . На практиці багато реалізацій REST насправді реалізують певний стан на сесії через щось на зразок OAuth.
Інша відмінність полягає в тому, що REST дуже орієнтований на ресурси або іменники . Ви взаємодієте з ресурсами за допомогою операцій CRUD. Все, що не відповідає цій парадигмі, стає громіздким і незграбним.
З іншого боку, SOAP - це лише протокол RPC (віддалений виклик процедури) . Це не з парадигмою, це лише транспортний шар.
REST також використовує пост. Насправді, коли використовуєте REST, дієслова http повідомляють про те, що відбувається.
REST і SOAP - це лише різні стандарти передачі даних через Інтернет.
Використовуючи обидва, я, як правило, рекомендую використовувати REST, а не SOAP, якщо ви не знаєте, хто використовує вашу веб-службу .net та Visual Studio. Зазвичай набагато простіше споживати веб-сервіс REST, за винятком .net VS, який робить більшу частину роботи для вас під час використання SOAP.
Одне, що я хотів би зазначити, - це сумісність - якщо ви збираєтесь зателефонувати на службу через додаток, написаний на .NET, а сервер написаний на Java (або будь-яка інша комбінація), тоді перейдіть на REST. Я бачив занадто багато незначних несумісностей між SOAP-реалізаціями, щоб перешкоджати цьому.
Якщо ви просто хочете простий, наочний посібник, який допоможе вам виміряти SOAP і REST відповідно до вимог ваших програм ...
Vijay Prasad Gupta склав просту та корисну діаграму.
Пряме посилання на блок-схему: https://drive.google.com/file/d/0B3zMtAq1Rf-sdVFNdThvNmZWRGc/edit
Посилання на статтю: https://www.linkedin.com/pulse/20140818062318-7933571-soap-vs-rest-flowchart-to-determine-the-right-web-services-protocol-for-your-needs
Зараз 2015 рік. Я б сподівався, що SOAP вже помер, але він все ще затримується, як неприємний запах. Що б то не було, окрім найпростіших прикладних прикладів, інтеграція з сервісом SOAP - це завдання. Це складна архітектура, що має безліч варіантів на декількох рівнях, поєднаних з примхами численних реалізацій та тонкою (і не настільки тонкою) несумісністю. Я ніколи не мав жодного хорошого досвіду з цим. REST, з іншого боку, вітер: всі розуміють HTTP. У більшості випадків JSON настільки набагато корисніший, ніж XML InfoSet.
Щоб дати уявлення про складність SOAP, спробуйте інтегрувати бібліотеку SOAP у свій проект. Для Java, найпростіший клієнт Apache Axis2 (використовуючи просту прив'язку даних ADB), включає 23 нові JAR. Двадцять три! 20 МБ бібліотеки. CXF схожий: 21 JAR, коли я востаннє рахував.
Якщо ви дійсно цього хотіли, ви можете зробити REST за допомогою простої бібліотеки HTTP.