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

Я би особливо цінував інформацію про ці концепції та їхнє відношення до всесвіту PHP, а також сучасні веб-додатки високого класу.

Я створив один з перших серверів SOAP, включаючи генерацію коду та генерацію WSDL, з оригінальної специфікації, яку розробляв, коли я працював у Hewlett-Packard. Я НЕ рекомендую використовувати SOAP ні для чого.

Скорочення "SOAP" - брехня. Це не просто, не є об'єктно-орієнтованим, воно не визначає правил доступу. Це, мабуть, протокол. Це найгірша специфіка Дон Бокса коли-небудь, і це цілком подвиг, оскільки він людина, яка здійснила "COM".

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

XML-RPC чітко визначає протоколи запитів, відповідей та помилок, і для більшості мов є хороші бібліотеки. Однак для багатьох завдань XML важче, ніж вам потрібно.

REST - це архітектура, SOAP - протокол.

Ось перша проблема.

Ви можете надсилати конверти SOAP у програмі REST.

Сам SOAP насправді є досить простим і простим, саме стандарти WSS- * роблять його дуже складним.

Якщо вашими споживачами є інші програми та інші сервери, сьогодні існує велика підтримка протоколу SOAP, а основи переміщення даних - це, по суті, клацання миші в сучасних ІДЕ.

Якщо ваші споживачі мають більше шансів бути клієнтами RIA або Ajax, ви, ймовірно, захочете чогось простішого, ніж SOAP та більш рідного для клієнта (зокрема JSON).

Пакети JSON, що надсилаються через HTTP, не обов'язково є архітектурою REST, це лише повідомлення на URL-адреси. Всі цілком справні, але є ключові компоненти ідіоми REST. Однак їх легко переплутати. Але тільки тому, що ви говорите HTTP-запити, не обов'язково означає, що у вас є архітектура REST. У вас може бути програма REST без HTTP (розум, це рідко).

Отже, якщо у вас є сервери та споживачі, які "зручні" з SOAP, SOAP та WSS стек можуть вам добре служити. Якщо ви робите більше спеціальних речей і хочете покращити взаємодію з веб-браузерами, то і легший протокол через HTTP також може добре працювати.

REST - принципово інша парадигма від SOAP. Почитати REST можна тут: Як я пояснив REST дружині .

Якщо у вас немає часу для його читання, ось коротка версія: REST - це трохи зміна парадигми, орієнтуючись на «іменники» та обмежуючи кількість «дієслів», які ви можете застосувати до цих іменників. Єдині дозволені дієслова - «дістати», «поставити», «опублікувати» та «видалити». Це відрізняється від SOAP, коли багато різних дієслів можна застосувати до багатьох різних іменників (тобто багато різних функцій).

Для REST чотири дієслова відображають відповідні запити HTTP, тоді як іменники ідентифікуються за URL-адресами. Це робить управління державою набагато прозорішим, ніж у SOAP, де часто незрозуміло, який стан знаходиться на сервері та що у клієнта.

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

Швидке вирішення питання для 2012 року:

Сфери, для яких REST дуже добре працює, це:

• Обмежена пропускна здатність та ресурси. Пам'ятайте, що структура повернення дійсно є в будь-якому форматі (визначено розробником). Крім того, будь-який браузер може бути використаний, оскільки підхід REST використовує стандартні дієслова GET, PUT, POST та DELETE. Знову ж таки, пам’ятайте, що REST також може використовувати об’єкт XMLHttpRequest, який сьогодні підтримують більшість сучасних браузерів, що додає додатковий бонус AJAX.

• Повністю операції без громадянства.  Якщо операцію потрібно продовжувати, REST - це не найкращий підхід, і SOAP може її краще підходити. Однак якщо вам потрібні операції CRUD без громадянства (Створення, читання, оновлення та видалення), то REST це.

• Ситуації кешування.  Якщо інформація може бути кешована через повністю бездержавну роботу підходу REST, це ідеально. Це охоплює безліч рішень у вищезгаданих трьох.

То чому б я навіть вважав SOAP? Знову ж таки, SOAP є досить зрілим та чітко визначеним і має повну специфікацію. Підхід REST - це саме це, підхід і широко відкритий для розвитку, тому якщо у вас є наступне, то SOAP - чудове рішення:

• Асинхронна обробка та виклик.  Якщо вашій програмі потрібен гарантований рівень надійності та безпеки, то SOAP 1.2 пропонує додаткові стандарти для забезпечення такого типу роботи. Такі речі, як WSRM - WS-надійний обмін повідомленнями.

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

• Державні операції. Якщо програмі потрібна контекстна інформація та керування розмовними станами, то SOAP 1.2 має додаткову специфікацію в структурі WS * для підтримки цих речей (безпека, транзакції, координація тощо). Порівняно, підхід REST змусив би розробників побудувати цю власну сантехніку.

http://www.infoq.com/articles/rest-soap-when-to-use-each

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

REST простіший, його можна легше підтримувати, як результат, лежить в основі веб-архітектури, дозволяє покращити видимість протоколів, і було доведено масштабувати розміри самої WWW. Деякі рамки там допомагають вам створювати REST-сервіси, наприклад, Ruby on Rails, а деякі навіть допомагають вам писати клієнтів, наприклад, ADO.NET Data Services. Але здебільшого бракує підтримки інструментів.

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

REST чудово поєднується з веб-сторінками AJAX. Якщо ви просто зберігаєте свої запити, ви можете здійснювати дзвінки по службі безпосередньо зі свого JavaScript, і це дуже зручно. Постарайтеся уникати просторів імен у відповіді XML, я бачив, як браузери задушуються над ними. Отже, xsi: type, ймовірно, не працює для вас, не надто складні XML-схеми.

REST також має кращі результати. Вимоги до ЦП до коду, що генерує відповіді REST, як правило, нижчі, ніж у рамках SOAP. І якщо у вас на сервер вишикуються качки покоління XML, ви можете ефективно передавати XML клієнту. Отже, уявіть, що ви читаєте рядки курсору бази даних. Під час читання рядка ви форматуєте його як XML-елемент, і ви пишете це безпосередньо споживачеві послуги. Таким чином, вам не доведеться збирати всі рядки бази даних у пам'яті, перш ніж починати писати свій XML-вихід - ви читаєте і пишете одночасно. Подивіться на нові двигуни-шаблони або XSLT, щоб поточне передавання працювало на REST.

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

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

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

Я знаю, що це давнє запитання, але я мушу опублікувати свою відповідь - можливо, хтось вважатиме це корисним. Я не можу повірити, скільки людей рекомендують REST через SOAP. Я можу лише припустити, що ці люди не є розробниками або ніколи не реалізували послугу REST будь-якого розумного розміру. Реалізація послуги REST займає багато часу, ніж реалізація послуги SOAP. І врешті-решт це теж виходить набагато грізнішим. Ось причини, з яких я б обрав SOAP 99% часу:

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

2) Навіщо писати послугу REST, яка все одно повертає XML? Єдина відмінність полягає в тому, що за допомогою REST ви не знаєте типів, які представляє кожен елемент / атрибут - ви самостійно реалізуєте це і сподіваєтесь, що одного дня рядок не натрапить на поле, яке ви вважали завжди int. SOAP визначає структуру даних за допомогою WSDL, тому це не потрібно.

3) Я чув скаргу на те, що за допомогою SOAP у вас є "накладні витрати" конверта SOAP. Чи нам в цей день і вік справді потрібно турбуватися про жменю байтів?

4) Я чув аргумент, що за допомогою REST ви можете просто запустити URL-адресу в браузер і переглянути дані. Звичайно, якщо ваша послуга REST використовує просту аутентифікацію або її відсутність. Наприклад, сервіс Netflix використовує OAuth, який вимагає від вас підписувати речі та кодувати речі, перш ніж ви навіть можете подати запит.

5) Навіщо нам потрібна "читабельна" URL-адреса для кожного ресурсу? Якщо ми використовували інструмент для впровадження послуги, чи нас справді цікавить фактична URL-адреса?

Потрібно, щоб я продовжував?

Більшість застосунків, які я пишу, - це сервер C + або Java, або настільні додатки в WinForms або WPF. Ці програми, як правило, потребують більш API API обслуговування, ніж REST може надати. Крім того, я не хочу витрачати більше ніж пару хвилин на створення свого клієнта веб-служб. Засоби генерації клієнтів для WSDL обробки дозволяють мені реалізувати свого клієнта та перейти до додавання ділової вартості.

Тепер, якби я явно писав веб-службу для якихось викликів jaja ajax, він, ймовірно, був би в REST; просто заради знання клієнтської технології та використання JSON. На мою думку, API веб-служб, що використовуються з JavaScript, мабуть, не повинен бути дуже складним, оскільки такий тип складності здається краще керованим на сервері.

Зважаючи на це, є деякі клієнти SOAP для JavaScript; Я знаю, що у jQuery є такий. Таким чином, SOAP можна використовувати з JavaScript; просто не так красиво, як служба REST, що повертає рядки JSON. Тож якби у мене був веб-сервіс, який я хотів би бути досить складним, щоб він був гнучким для довільної кількості клієнтських технологій та застосувань, я б пішов із SOAP.

Я рекомендую спершу перейти з REST - якщо ви використовуєте Java, подивіться на JAX-RS та реалізацію Джерсі . REST набагато простіший та легкий для взаємодії на багатьох мовах.

Як говорили інші в цій темі, проблема з SOAP полягає в її складності, коли входять інші специфікації WS- * і виникає незліченна кількість проблем взаємодії, якщо ви потрапили в неправильні частини WSDL, XSD, SOAP, WS-адресація тощо.

Найкращий спосіб судити дебати REST v SOAP - це шукати в Інтернеті - майже всі великі гравці у веб-просторі, google, amazon, ebay, twitter та ін - схильні використовувати та віддавати перевагу API RESTful перед SOAP.

Іншим приємним підходом до роботи з REST є те, що ви можете повторно використовувати багато коду та інфраструктури між веб-додатком та передньою частиною REST. наприклад, рендерінг HTML проти XML та JSON ваших ресурсів, як правило, досить простий з такими рамками, як JAX-RS та неявні перегляди - плюс його легкість у роботі з ресурсами RESTful за допомогою веб-браузера

Я впевнений, що Дон Бокс створив SOAP як жарт - «дивись, ти можеш викликати методи RPC через Інтернет» і сьогодні стогне, коли він усвідомлює, яким роздутим кошмаром веб-стандартів він став :-)

REST хороший, простий, впроваджується скрізь (настільки більше «стандарт», ніж стандарти) швидко та легко. Використовуйте REST.

Я думаю, що в обох є своє місце. На мою думку:

SOAP : Кращий вибір для інтеграції застарілих / критичних систем та системи веб / веб-сервісу на фундаментальному шарі, де WS- * має сенс (безпека, політика тощо).

RESTful : Кращий вибір для інтеграції веб-сайтів, із загальнодоступним API, на верхньому рівні шару (VIEW, тобто javascripts, що приймає дзвінки до URI).

Одне, що не згадувалося, - конверт SOAP може містити заголовки, а також частини тіла. Це дозволяє використовувати повну виразність XML для надсилання та отримання інформації про смуги. REST, наскільки мені відомо, обмежує вас заголовками HTTP та кодами результатів.

(Ото, чи можете ви використовувати файли cookie з послугою REST для надсилання типу "заголовка" з даних про діапазон?)

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

Відповідаючи на оновлений (другий щедрий) питання 2012 року та переглядаючи сьогоднішні результати (інші відповіді).

Мило, плюси і мінуси

Про SOAP 1.2, переваги та недоліки при порівнянні з "REST" ... Ну, з 2007 року ви можете описати веб-сервіси REST за допомогою WSDL та за допомогою протоколу SOAP ... Тобто, якщо ви працюєте трохи складніше, всі стандарти W3C стек протоколів веб-служб може бути REST !

Це хороший вихідний пункт, адже ми можемо уявити сценарій, коли тимчасово уникають усіх філософських та методологічних дискусій. Ми можемо порівняти технічно "SOAP-REST" з "NON-SOAP-REST" у подібних сервісах,

• SOAP-REST (= "REST-SOAP"): як показав L.Mandel , WSDL2 може описати веб- сервіс REST, і, якщо ми припустимо, що приклад XML може бути охоплений SOAP, вся реалізація буде "SOAP-REST" .

• НЕ МОЖЛИВИЙ РЕСТ : будь-який веб-сервіс REST, який не може бути SOAP ... Тобто "90%" добре відомих прикладів REST. Деякі не використовують XML (наприклад, типові AJAX REST використовують замість JSON), інші використовують інші структури XML, без заголовків або правил SOAP. PS: щоб уникнути неформальності, ми можемо припустити рівень REST 2 у порівняннях.

Звичайно, щоб порівняти більш концептуально, порівняйте "NON-REST-SOAP" з "NON-SOAP-REST", як різні підходи моделювання. Отже, виконавши цю систематику веб-служб:

• НЕ-РЕСТ-SOAP : будь-який веб-сервіс SOAP, який не може бути REST ... Тобто "90%" добре відомих прикладів SOAP.

• НЕ ВІДПОВІДНО-НІКОЛИ-МУП : так, всесвіт "моделювання веб-служб" включає в себе інші речі (наприклад, XML-RPC ).

Мило в умовах REST

Порівнюючи порівнянні речі: SOAP-REST з NON-SOAP-REST .

ПРОС

Пояснюючи деякі терміни,

• Контрактна стабільність : для всіх видів договорів (як "письмові угоди"),

  • За допомогою стандартів : всі рівні стеку W3C взаємопов'язані. REST, з іншого боку, не є стандартом W3C або ISO і не має нормованих деталей щодо периферійних пристроїв сервісу. Отже, як я вже говорив, @DaveWoldrich (20 голосів), @cynicman (5), @Exitos (0), в контексті, де НЕОБХІДНІ ДЛЯ СТАНДАРТІВ, вам потрібне мило.

  • За використання передової практики : в «розширений аспекті» з стека W3C реалізацій, переводить відповідний людина / юридичної / juridic угоди.

• Міцність : безпека структури SOAP та заголовків. За допомогою метаданих зв'язку (з повною виразністю XML) та перевірки у вас є "страховий поліс" від будь-яких змін або шуму.
  SOAP має "транзакційну надійність (...) вирішувати проблеми з комунікацією. SOAP має більше контролю над логікою повторної спроби, і, таким чином, може забезпечити більше надійності та гарантій обслуговування", Е. Терман .

Сортування профі за популярністю,

• Кращі інструменти (~ 70 голосів): SOAP в даний час має перевагу кращих інструментів, починаючи з 2007 і по 2012 рік, оскільки це чітко визначений і широко прийнятий стандарт. Дивіться @MarkCidade (27 голосів), @DaveWoldrich (20), @JoshM (13), @TravisHeseman (9).

• Стандарти відповідність (25 голосів): як я , @DaveWoldrich (20 голосів), @cynicman (5), @Exitos (0) раніше, в контексті, де НЕОБХІДНІ ДЛЯ СТАНДАРТІВ, вам потрібне мило.

• Міцність : страхування заголовків SOAP, @JohnSaunders (8 голосів).

КОНС

• Структура SOAP є більш складною (більше 300 голосів): усі відповіді та джерела про "SOAP vs REST" виявляють певну ступінь неприязнь до надмірності та складності SOAP. Це природний наслідок вимог як до формальної перевірки (див. Нижче), так і для надійності (див. Вище). "REST NON-SOAP" (і XML-RPC, джерело SOAP ) може бути більш простим та неформальним.

• Обмеження "єдиного XML" є перешкодою для роботи при використанні крихітних сервісів (~ 50 голосів): див. Json.org/xml і це питання , або це інше . Цю точку показали @toluju (41) та інші.
  PS: оскільки JSON не є стандартом IETF , але ми можемо вважати фактичним стандартом для спільноти програмного забезпечення веб.

Послуги моделювання за допомогою SOAP

Тепер ми можемо додати SOAP-NON-REST зі порівнянням NON-SOAP-REST та пояснити, коли краще використовувати SOAP :

• Потреба в стандартах та стабільних контрактах (див. Розділ "PROS"). PS: див . Типову "потребу в B2B стандартах", описану @saille .

• Потреба в інструментах (див. Розділ "PROS"). PS: стандарти та наявність офіційних перевірок (див. Нижче) є важливими питаннями для автоматизації інструментів.

• Паралельна важка обробка (див. Розділ "Контекст / основи" нижче): більші та / або повільніші процеси, незалежно від дедалі більшої складності SOAP, надійність та стабільність - найкращі інвестиції.

• Потрібна більша безпека : коли потрібно більше HTTPS і вам справді потрібні додаткові функції для захисту, SOAP - кращий вибір ( див. @Bell , 32 голоси). "Надсилання повідомлення вздовж шляху, складнішого, ніж запит / відповідь, або через транспорт, який не передбачає HTTP", С. Зелі . XML є основною проблемою, пропонуючи стандарти XML Encryption , XML Signature і канонізація XML , і, тільки з SOAP ви можете включити ці механізми в повідомленні на загальноприйнятий стандарт , як WS-Security .

• Потрібна більша гнучкість (менше обмежень): SOAP не потребує точного листування з URI; не Nedd обмежувати HTTP; не потрібно обмежуватися 4 дієсловами. Як говорить @TravisHeseman (9 голосів), якщо ви хотіли чогось "гнучкого для довільної кількості клієнтських технологій та використання", використовуйте SOAP.
  PS: пам’ятайте, що XML є більш універсальним / виразним, ніж JSON (та ін.)

• Необхідність формальної перевірки : важливо розуміти, що стек W3C використовує формальні методи , а REST - неформальніший. Опис послуги WSDL ( формальної мови ) - це формальна специфікація ваших веб-сервісів, а SOAP - надійний протокол, який приймає всі можливі приписи WSDL.

КОНТЕКСТ

Історичний

Для оцінки тенденцій необхідна історична перспектива. Для цієї теми перспектива на 10 або 15 років ...

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

Для щоденних завдань, таких як реалізація AJAX, SOAP важкий ... Отже, необхідність у простих підходах потребує обрання нової теоретичної основи ... І великих "програвачів веб-програм", як Google, Amazon, Yahoo та ін. Обрали найкращу альтернативу, тобто підхід REST. Якщо в цьому контексті концепція REST постала як "конкуруючий фреймворк", і сьогодні (2012 рік) ця альтернатива є фактично стандартом для програмістів.

Основи

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

У міру того, як завдання стає більшим, воно стає менш значним "дискусією щодо складності", а також стає більш актуальною надійність зв'язку та міцність договорів.

Це нюанс.

Якщо вам потрібен інший системний інтерфейс з вашими послугами, то багато клієнтів будуть щасливішими з SOAP, завдяки шарам "перевірки", які ви маєте з контрактами, WSDL та стандартом SOAP.

Для щоденних систем, що входять у системи, я думаю, що SOAP - це багато зайвих накладних витрат, коли простий HTML-дзвінок буде робити.

Я дивлюся на те саме, і я думаю, що вони різні інструменти для різних проблем .

Простий протокол доступу до об’єктів (SOAP), стандарт XML, що визначає архітектуру повідомлень та формати повідомлень, використовується веб-службами, що містять опис операцій. WSDL - це заснована на XML мова для опису веб-служб та способів доступу до них. буде працювати на SMTP, HTTP, FTP і т.д.

Веб-сервіси представницьких державних трансфертів (RESTful). вони є веб-сервісами другого покоління. RESTful веб-сервіси, спілкуються через HTTP, ніж послуги на основі SOAP, і не потребують XML-повідомлень або WSDL-служб-API-визначень. для REST не потрібно проміжне програмне забезпечення, потрібна лише підтримка HTTP.WADL Standard, REST може повернути XML, звичайний текст, JSON, HTML тощо

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

1. REST використовує стандартний HTTP, так що простіше створювати клієнтів, розробляти API
2. REST дозволяє використовувати безліч різних форматів даних, таких як XML, звичайний текст, JSON, HTML, де SOAP дозволяє лише XML.
3. REST має кращі показники та масштабованість.
4. Відпочинок і кешування, а SOAP не може
5. Вбудована обробка помилок, де SOAP не має помилок
6. REST особливо корисний КПК та інших мобільних пристроїв.

REST - послуги легко інтегрувати з існуючими веб-сайтами.

SOAP має набір протоколів, які, серед іншого, забезпечують стандарти безпеки та надійності та взаємодіють з іншими клієнтами та серверами, що відповідають WS. Веб-сервіси SOAP (наприклад, JAX-WS) корисні для обробки асинхронної обробки та виклику.

Для складних API SOAP буде кориснішим.

REST - це архітектура, винайдена Роєм Філдінгом і описана в його дисертації « Архітектурні стилі та дизайн мережевих програмних архітектур» . Рой також є головним автором HTTP - протоколу, який визначає передачу документів по всесвітній мережі. HTTP - це протокол RESTful. Коли розробники говорять про "використання веб-сервісів REST", мабуть, точніше сказати "використання HTTP".

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

Перш ніж створити веб-сервіс, я рекомендую вивчити HTTP. Шанси на те, що ваші вимоги можуть бути реалізовані за допомогою функціоналу, визначеного в специфікації, тому інші протоколи не знадобляться.

Я дивлюся на те саме питання. Мені здається, що насправді REST - це швидкий і простий і хороший для легких дзвінків та відповідей і чудово підходить для налагодження (що може бути краще, ніж завантажувати URL-адресу в браузер і бачити відповідь).

Однак там, де REST падає, це пов'язано з тим, що він не є стандартом (хоча складається з стандартів). Більшість бібліотек програмування мають можливість перевірити WSDL для автоматичного генерування клієнтського коду, необхідного для споживання послуг на базі SOAP. Таким чином, споживання веб-служб на основі REST здається більш прихильним підходом до написання інтерфейсу, щоб відповідати можливим дзвінкам. Зробити http-запит вручну, потім проаналізувати відповідь. Це саме по собі може бути небезпечним.

Краса SOAP полягає в тому, що як тільки WSDL буде виданий, то бізнес 'може структурувати свою логічну дію, яка встановить контракт, будь-яка зміна інтерфейсу змінить wsdl. Немає жодного приміщення для маневру. Ви можете перевірити всі запити щодо цієї WSDL. Однак оскільки WSDL не описує належним чином послугу REST, то у вас немає визначеного способу узгодження інтерфейсу для спілкування.

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

Верхній "Відповідь" у цій темі, схоже, говорить про те, що SOAP розшифровується як Простий об'єктно-орієнтований протокол доступу, проте, дивлячись на wiki О, це означає, що об'єкт не орієнтований на об'єкт. Вони різні речі.

Я знаю, що цей пост дуже старий, але думав, що слід відповісти власними висновками.

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

Мені цікаво, що думають інші.

Прослухайте цей подкаст, щоб дізнатися. Якщо ви хочете знати відповідь, не слухаючи, тоді добре, її REST. Але я дійсно рекомендую слухати.

Моє загальне правило: якщо ви хочете, щоб веб-клієнт веб-переглядача безпосередньо підключився до послуги, ви, ймовірно, повинні використовувати REST. Якщо ви хочете передати структуровані дані між резервними службами, тоді використовуйте SOAP.

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

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

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

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

У сенсі "PHP-всесвіт" підтримка PHP для будь-якого вдосконаленого SOAP забирає великий час. Ви в кінцевому підсумку використовуєте щось на зразок http://wso2.com/products/web-services-framework/php/ як тільки перейдете основні потреби, навіть для того, щоб WS-Security або WS-RM не мали вбудованої підтримки.

Створення конвертів SOAP Я відчуваю, що в PHP сильно заплутано, як він створює простори імен, xsd: nil, xsd: будь-який тип і старе мило, що використовується у стилі.

Уникайте всього цього безладу, дотримуючись REST, REST - це нічого насправді великого, яким ми користуємось з початку WWW. Ми зрозуміли лише тоді, коли це http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm вийшов документ , він показує, як можна використовувати можливості HTTP для впровадження RESTFul Services. HTTP по суті є REST, це не означає, що лише використання HTTP робить ваші послуги RESTFul.

SOAP нехтує основними можливостями HTTP і розглядає HTTP лише як транспортний протокол, отже, він є теоретичним незалежним протоколом транспорту (на практиці це не так, чи ви чули про заголовок SOAP Action? Якщо не google - це зараз!).

Зі збільшенням адаптації JSON та HTML5 із дозріванням javascript REST з JSON стали найпоширенішим способом роботи з послугами. Також було визначено схему JSON, яку можна використовувати для рішень на рівні підприємства (ще на ранніх етапах) разом із WADL.

Підтримка PHP для REST та JSON, безумовно, краща, ніж наявна вбудована підтримка SOAP.

Додаючи сюди ще кілька слів BUZZ SOA, WOA, ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

до речі, я люблю SOAP, особливо для специфікації WS-Security, це одна хороша специфікація, і якщо хтось, хто думає про адаптацію Enterprise JSON, безумовно, повинен придумати щось подібне для JSON, наприклад, шифрування на рівні поля тощо.

Один швидкий момент - протокол передачі та оркестрація;

Я використовую SOAP через TCP з міркувань швидкості, надійності та безпеки, включаючи організовану машину для машинного обслуговування (ESB) та для зовнішніх служб. Змінивши визначення сервісу, оркестрація викликає помилку від зміни WSDL і її відразу очевидна і може бути перебудована / розгорнута.

Не впевнений, що ви можете зробити те ж саме з REST - я чекаю, що вас виправлять або пройдуть курс! За допомогою REST змініть визначення послуги - нічого про це не знаєте, поки він не поверне 400 (або що завгодно).

Якщо ви шукаєте інтероперабельність між різними системами та мовами, я б неодмінно пішов на REST. У мене було чимало проблем, намагаючись, наприклад, SOAP працювати між .NET та Java.

я створюю орієнтир, щоб знайти, хто з них швидший! я бачу цей результат:

на 1000 запитів:

• REST зайняв 3 секунди
• SOAP зайняв 7 секунди

для 10 000 запитів:

• REST зайняв 33 секунди
• SOAP зайняв 69 секунди

для 1 000 000 запитів:

• REST зайняв 62 секунди
• SOAP зайняв 114 секунди

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

Моя робота передбачає розробку та розробку рішень IoT (Internet of Things). Що включає розробку коду для невеликих вбудованих пристроїв, які спілкуються з Cloud.

Зрозуміло, що REST зараз широко прийнятий і корисний, і це майже стандарт дефакто для Інтернету, навіть Microsoft має підтримку REST, включену в Azure. Якщо мені потрібно було покластися на SOAP, я не міг би зробити те, що мені потрібно робити, як це занадто велике, об'ємне і дратівливе для маленьких вбудованих пристроїв.

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

1.З мого досвіду. Я б сказав, що REST надає вам доступ до вже створеної URL-адреси. наприклад-> пошук слова в google. Ця URL-адреса може використовуватися як веб-сервіс для REST. У SOAP ви можете створити власну веб-службу та отримати доступ до неї через клієнт SOAP.

2. REST підтримує текст, формат JSON, XML. Отже, більш універсальний для спілкування між двома програмами. Хоча SOAP підтримує лише формат XML для повідомлення повідомлень.