Четох статии за разликите между SOAP и REST като протокол за комуникация на уеб услуги, но мисля, че най-големите предимства на REST пред SOAP са:
REST е по-динамичен, не е необходимо да се създава и актуализира UDDI (Universal Description, Discovery, and Integration).
REST не се ограничава само до XML формат. REST уеб услугите могат да изпращат обикновен текст/JSON/XML.
Но SOAP е по-стандартизиран (напр.: сигурност).
И така, прав ли съм по тези въпроси?
За съжаление, има много погрешна информация и погрешни схващания за REST. Не само вашият въпрос и отговорът на @cmd отразяват това, но и повечето въпроси и отговори, свързани с темата, в Stack Overflow. SOAP и REST не могат да се сравняват директно, тъй като първият е протокол (или поне се опитва да бъде), а вторият е архитектурен стил. Това вероятно е един от източниците на объркване около него, тъй като хората са склонни да наричат REST всеки HTTP API, който не е SOAP. Като се поразровим малко и се опитаме да направим сравнение, основната разлика между SOAP и REST е степента на обвързаност между клиентските и сървърните реализации. SOAP клиентът работи като персонализирано настолно приложение, което е тясно свързано със сървъра. Между клиента и сървъра има твърд договор и се очаква всичко да се счупи, ако някоя от страните промени нещо. Необходими са постоянни актуализации след всяка промяна, но е по-лесно да се установи дали договорът се спазва. REST клиентът е по-скоро като браузър. Това е общ клиент, който знае как да използва протокол и стандартизирани методи, а приложението трябва да се вмести в него. Вие не нарушавате стандартите на протокола, като създавате допълнителни методи, а използвате стандартните методи и създавате действия с тях на вашия тип медия. Ако това е направено правилно, връзката е по-малка и промените могат да се обработват по-ефикасно. Предполага се, че клиентът влиза в REST услуга с нулеви познания за API, освен за входната точка и медийния тип. В SOAP клиентът се нуждае от предварителни познания за всичко, което ще използва, иначе дори няма да започне взаимодействието. Освен това REST клиентът може да бъде разширен с код по заявка, предоставен от самия сървър, като класическият пример е код на JavaScript, използван за управление на взаимодействието с друга услуга от страна на клиента. Мисля, че това са най-важните моменти, за да се разбере какво представлява REST и по какво се различава от SOAP:
stackoverflow.com/questions/<id>
, да замените id с Question.id и да го поставите в браузъра си. Това е глупост, но много хора смятат, че REST е именно това.
Последната точка не може да се подчертае достатъчно. Ако вашите клиенти изграждат URI от шаблони в документацията и не получават връзки в представянето на ресурсите, това'не е REST. Рой Филдинг, авторът на REST, го е казал ясно в тази публикация в блога: REST API трябва да са хипертекстови.
Като имате предвид горното, ще разберете, че макар REST да не е ограничен до XML, за да го направите правилно с всеки друг формат, ще трябва да разработите и стандартизирате някакъв формат за вашите връзки. Хипервръзките са стандартни в XML, но не и в JSON. Съществуват проекти на стандарти за JSON, като например HAL.
И накрая, REST не'е за всеки и доказателство за това е как повечето хора решават много добре проблемите си с HTTP API, които погрешно наричат REST, и никога не излизат извън рамките на това. REST е труден за изпълнение понякога, особено в началото, но с времето се отплаща с по-лесното развитие от страна на сървъра и устойчивостта на клиента'към промени. Ако трябва да направите нещо бързо и лесно, не се притеснявайте да се справите с REST. Вероятно това не е това, което търсите. Ако ви трябва нещо, което ще остане онлайн години или дори десетилетия, тогава REST е за вас.REST
срещу SOAP
е не правилният въпрос, който трябва да зададете.
REST
, за разлика от SOAP
, е не протокол.
REST
е архитектурен стил и проект за мрежово базирани софтуерни архитектури.
Концепциите на REST
се наричат ресурси. Представянето на ресурс трябва да е без състояние. Той се представя чрез някакъв медиен тип. Някои примери за медийни типове включват XML
, JSON
и RDF
. Ресурсите се манипулират от компоненти. Компонентите заявяват и манипулират ресурси чрез стандартен унифициран интерфейс. В случая на HTTP този интерфейс се състои от стандартни HTTP операции, например GET
, PUT
, POST
, DELETE
.
Въпросът на @Abdulaziz'наистина осветлява факта, че REST
и HTTP
често се използват заедно. Това се дължи най-вече на простотата на HTTP и на много естественото му пренасяне към принципите на RESTful.
Комуникация между клиент и сървър
Архитектурите клиент-сървър се характеризират с много ясно разделение на проблемите. Всички приложения, изградени в стила RESTful, също трябва да са клиент-сървър по принцип.
Безсъставен
Всяка клиентска заявка към сървъра изисква неговото състояние да бъде напълно представено. Сървърът трябва да може напълно да разбере клиентската заявка, без да използва никакъв контекст на сървъра или състояние на сесията на сървъра. От това следва, че цялото състояние трябва да се съхранява на клиента.
Кешируем
Могат да се използват ограничения за кеширане, като по този начин данните за отговора могат да бъдат маркирани като кешируеми или некешируеми. Всички данни, маркирани като кешируеми, могат да се използват повторно като отговор на същата последваща заявка.
Унифициран интерфейс
Всички компоненти трябва да си взаимодействат чрез единен унифициран интерфейс. Тъй като цялото взаимодействие на компонентите се осъществява чрез този интерфейс, взаимодействието с различни услуги е много просто. Интерфейсът е един и същ! Това също така означава, че промените в имплементацията могат да се правят изолирано. Такива промени няма да повлияят на основното взаимодействие на компонентите, тъй като единният интерфейс е винаги непроменен. Един от недостатъците е, че сте привързани към този интерфейс. Ако може да се осигури оптимизация на определена услуга чрез промяна на интерфейса, нямате късмет, тъй като REST забранява това. От друга страна обаче, REST е оптимизиран за уеб, откъдето идва и невероятната популярност на REST по HTTP!
Горните понятия представляват определящи характеристики на REST и отличават архитектурата REST от други архитектури като уеб услуги. Полезно е да се отбележи, че REST услугата е уеб услуга, но уеб услугата не е непременно REST услуга.
За повече подробности относно REST и посочените по-горе точки вижте тази публикация в блога 1 на тема REST Design Principles.
ЕДИТ: актуализиране на съдържанието въз основа на коментари
SOAP (Прост протокол за достъп до обекти) и REST (Прехвърляне на състояние на представяне) са красиви по свой начин. Затова няма да ги сравнявам. Вместо това се опитвам да обрисувам картината, кога предпочитам да използвам REST и кога SOAP.
Какво е полезен товар?
Когато се изпращат данни по интернет, всяка предадена единица включва както информация от заглавието, така и действителните данни, които се изпращат. Заглавието идентифицира източника и местоназначението на пакета, а действителните данни се наричат полезен товар. Като цяло полезният товар са данните, които се пренасят от името на дадено приложение, и данните, получени от системата на местоназначението.
Сега, например, трябва да изпратя телеграма и всички знаем, че цената на телеграмата ще зависи от някои думи.
Така че ми кажете кое от посочените по-долу две съобщения е по-евтино за изпращане?
<name>Arin</name>
или
"name": "Arin"
Знам, че отговорът ви ще бъде вторият, въпреки че и двата представляват едно и също съобщение, вторият е по-евтин по отношение на разходите.
Затова се опитвам да кажа, че изпращането на данни по мрежата във формат JSON е по-евтино от изпращането им във формат XML по отношение на полезния товар.
Това е първата полза или предимство на REST пред SOAP. SOAP поддържа само XML, а REST поддържа различни формати като текст, JSON, XML и т.н. А вече знаем, че ако използваме Json, определено ще сме на по-добро място по отношение на полезния товар.
Сега SOAP поддържа само XML, но и той има своите предимства.
Наистина! Как?
SOAP разчита на XML по три начина Плик - определя какво съдържа съобщението и как да бъде обработено.
Набор от правила за кодиране на типовете данни и накрая оформлението на събраните извиквания на процедури и отговори.
Този плик се изпраща чрез транспорт (HTTP/HTTPS) и се изпълнява RPC (Remote Procedure Call - отдалечено извикване на процедура), а пликът се връща с информация в документ, форматиран в XML.
Важното е, че едно от предимствата на SOAP е използването на "общ" транспорт, но REST използва HTTP/HTTPS. SOAP може да използва почти всеки транспорт за изпращане на заявката, но REST не може. Така че тук имаме предимство на използването на SOAP.
Както вече споменах в по-горния параграф, "REST използва HTTP/HTTPS ", така че вникнете малко по-дълбоко в тези думи.
Когато говорим за REST по HTTP, всички мерки за сигурност, прилагани по HTTP, се наследяват и това е известно като сигурност на транспортно ниво и тя защитава съобщенията само докато са вътре в жицата, но след като ги предадете от другата страна, не знаете през колко етапа ще трябва да преминат, преди да достигнат до реалната точка, където данните ще бъдат обработени. И, разбира се, всички тези етапи могат да използват нещо различно от HTTP.Така че Rest не е напълно безопасен, нали?
Но SOAP поддържа SSL също като REST, освен това поддържа и WS-Security, което добавя някои корпоративни функции за сигурност. WS-Security предлага защита от създаването на съобщението до неговото потребление. Така че за сигурността на транспортно ниво, каквато и пролука да открием, тя може да бъде предотвратена с помощта на WS-Security.
Освен това, тъй като REST е ограничен от протокола HTTP, поддръжката на транзакциите не е нито съвместима с ACID, нито може да осигури двуфазен commit в разпределени транснационални ресурси.
Но SOAP има цялостна поддръжка както за ACID-базирано управление на транзакции за краткотрайни транзакции, така и за компенсационно базирано управление на транзакции за дълготрайни транзакции. Той също така поддържа двуфазен commit за разпределени ресурси.
Не правя заключение, но ще предпочета SOAP-базираната уеб услуга, докато сигурността, транзакциите и т.н. са основните проблеми.
Ето "The Java EE 6 Tutorial", където се казва RESTful дизайнът може да е подходящ, когато са изпълнени следните условия. Погледнете.
Надявам се, че ви е харесало да прочетете отговора ми.