SOAP vs REST (skirtumai)

Aš perskaičiau straipsnius apie skirtumus tarp SOAP ir REST kaip žiniatinklio paslaugų ryšio protokolą, bet manau, kad didžiausia nauda REST per SOAP yra:

  • REST yra dinamiškesnė, nereikia kurti ir atnaujinti UDDI.

  • REST neapsiriboja XML. REST žiniatinklio paslaugos gali siųsti paprastą tekstą, JSON ir XML.

Tačiau SOAP yra labiau standartizuotas (pvz., Saugumas).

Taigi, ar aš teisus šiuose taškuose?

813
10 нояб. nustatė Abdulaziz 10 nov. 2013-11-10 02:11 '13, 2:11 2013-11-10 02:11
@ 12 atsakymų

Deja, „REST“ yra daug klaidingos informacijos ir klaidingos nuomonės. Ne tik jūsų klausimas ir atsakymas į @cmd atspindi juos, bet dauguma klausimų ir atsakymų, susijusių su temu, yra perkrovos viršuje .

SOAP ir REST negalima tiesiogiai palyginti, nes pirmasis yra protokolas (arba bent jau bando būti), o antrasis - architektūrinis. Tai tikriausiai yra vienas iš supainiojimo šaltinių, nes žmonės paprastai skambina REST bet kokia HTTP API, kuri nėra SOAP.

Šiek tiek skatinant dalykus ir bandant nustatyti palyginimą, pagrindinis skirtumas tarp SOAP ir REST yra kliento ir serverio sąveikos sąveikos laipsnis. SOAP klientas veikia kaip pasirinktinis darbalaukio taikymas, glaudžiai susijęs su serveriu. Yra sunki sutartis tarp kliento ir serverio, ir viskas, ko tikimasi, sulaužys, jei kuri nors pusė pasikeis. Po bet kokių pakeitimų jums reikės nuolatinių atnaujinimų, tačiau lengviau išsiaiškinti, ar laikomasi sutarties.

„REST“ klientas yra labiau panašus į naršyklę. Tai bendras klientas, kuris žino, kaip naudoti protokolą ir standartizuotus metodus, ir taikymas turi atitikti tai. Jūs nepažeidžiate protokolo standartų, sukuriate papildomų metodų, naudojate standartinius metodus ir su jais sukuriate veiksmus pagal savo laikmenos tipą. Jei tai daroma teisingai, yra mažiau nuorodų, o pakeitimai gali būti tvarkomi dar labiau. Daroma prielaida, kad klientas turi įvesti REST paslaugą be žinių apie API, išskyrus įvesties tašką ir laikmenos tipą. „SOAP“ klientui reikia ankstesnių žinių apie viską, ką ji naudos, arba net net pradės sąveiką. Be to, „REST“ klientas gali būti išplėstas pagal užsakovo pateiktą kodą, kurį pateikia pats serveris. Klasikinis pavyzdys yra „JavaScript“ kodas, naudojamas valdyti sąveiką su kita paslauga kliento pusėje.

Manau, kad tai yra labai svarbūs momentai suprasti, kas yra „REST“ ir kaip ji skiriasi nuo „SOAP“:

  • REST yra protokolo nepriklausomas. Jis nėra susijęs su HTTP. Daugeliu atvejų, kaip galite sekti ftp nuorodą svetainėje, REST programa gali naudoti bet kurį protokolą, kuriam yra standartizuota URI schema.

  • REST nėra CRUD susiejimas su HTTP metodais. Išsamiai paaiškinkite šį atsakymą.

  • REST yra standartizuota kaip jūsų naudojamos dalys. HTTP saugumas ir autentifikavimas yra standartizuoti, todėl naudojate REST per HTTP.

  • REST nėra REST be hipermedijos ir HATEOAS . Tai reiškia, kad klientas žino tik įėjimo taško URI, o ištekliai turi grąžinti nuorodas, kurias klientas turi laikytis. Šie išgalvoti dokumentacijos generatoriai, kurie teikia URI modelius viską, ką galite padaryti „REST API“, yra visiškai nepastebėti. Jie ne tik dokumentuoja, kas turėtų atitikti standartą, bet ir tai padarius, susieti klientą su vienu konkrečiu API raidos tašku, o bet kokie API pakeitimai turi būti dokumentuojami ir taikomi, arba jie bus pertraukiami.

  • REST yra pačios svetainės architektūros stilius. Kai įvesite „Stack Overflow“, žinosite, kas yra vartotojas, klausimas ir atsakymas, žinote žiniasklaidos tipus, o svetainėje pateikiama nuorodų į juos. REST API turėtų daryti tą patį. Jei sukūrėme internetą, kaip žmonės turėtų manyti, kad REST turėtų būti sukurtas, vietoj puslapio, kuriame būtų nuorodos į klausimus ir atsakymus, mes turėtume statinį dokumentą, paaiškinantį, kad norint peržiūrėti klausimą, kurį reikia užimti „ stackoverflow.com/questions/<id> URI stackoverflow.com/questions/<id> , pakeiskite ID su Klausimas.id ir įklijuokite jį į savo naršyklę. Tai yra nesąmonė, bet ką daugelis mano, kad REST.

Šis paskutinis punktas negali būti pakankamai pabrėžtas. Jei jūsų klientai sukuria URI iš šablonų dokumentacijoje ir negauna nuorodų išteklių vaizduose, tai nėra REST. Roest Fielding, REST autorius, paskelbė šį dienoraštį aiškų: REST API turėtų būti pagrįstas hipertekstu .

Remdamiesi tuo, kas išdėstyta pirmiau, jūs suprasite, kad, nors REST gali būti neapsiribojama XML, tinkamai dirbti su bet kuriuo kitu formatu, turėsite sukurti ir standartizuoti kai kuriuos savo nuorodų formatus. Hipersaitai yra standartiniai XML, bet ne JSON. JSON yra standartų standartai, pavyzdžiui, HAL .

Galiausiai, REST nėra skirtas visiems, ir tai įrodo, kaip dauguma žmonių labai gerai išsprendžia problemas, susijusias su HTTP API, kurias jie klaidingai vadina REST, ir niekada neviršija to. Kartais „REST“ sunku padaryti, ypač pradžioje, tačiau jis per tam tikrą laiką moka lengviau serverio pusės evoliuciją ir klientų atsparumą pokyčiams. Jei jums reikia ką nors greitai ir lengvai padaryti, nesijaudinkite, kad gausite tinkamą REST. Tai tikriausiai ne tai, ko ieškote. Jei jums reikia kažko, kas reikės išlikti internete jau daug metų ar net dešimtmečių, tuomet REST yra skirtas jums.

1245
10 нояб. Atsakymą pateikė Pedro Werneck 10 lapkričio. 2013-11-10 03:45 '13, 03:45 am 2013-11-10 03:45

REST vs SOAP nėra teisingas klausimas.

REST , skirtingai nei SOAP , nėra protokolas.

REST yra architektūros stilius ir programinės įrangos pagrindu sukurtos tinklo architektūros.

REST koncepcijos vadinamos ištekliais. Išteklių pateikimas turi būti neaktyvus. Ji pateikiama per tam tikros rūšies žiniasklaidą. Kai kurie žiniasklaidos tipų pavyzdžiai yra XML , JSON ir RDF . Ištekliai tvarkomi komponentais. Komponentai prašo ir valdo išteklius naudodami standartinę vieningą sąsają. HTTP atveju ši sąsaja susideda iš standartinių HTTP operacijų. GET , PUT , POST , DELETE .

Klausimas

@Abdulazizas apima tai, kad REST ir HTTP dažnai naudojami kartu. Tai visų pirma yra dėl HTTP paprastumo ir natūralaus žemėlapio, skirto „RESTful“ principams.

Pagrindiniai REST principai

Kliento serverio ryšys

Klientų ir serverių architektūros turi labai aiškų problemų atskyrimą. Visi „RESTful“ stiliumi sukurti prašymai taip pat turėtų būti kliento-serverio principas.

Be pilietybės

border=0

Kiekvienam kliento užsakymui serveryje reikia, kad jo statusas būtų pilnai atvaizduotas. Serveris turi sugebėti visiškai suprasti kliento užklausą nenaudodamas jokios serverio būsenos ar serverio sesijos būsenos. Iš to išplaukia, kad visa valstybė turi būti laikoma kliente.

Cacheable

Galima naudoti talpyklą ribojančius apribojimus, leidžiančius nurodyti atsakymo duomenis kaip įrašančius arba nepavojingus. Bet kokie talpykloje pažymėti duomenys gali būti pakartotinai naudojami kaip atsakymas į tą patį vėlesnį prašymą.

Vienoda sąsaja

Visi komponentai turi sąveikauti vienoje vienoje sąsajoje. Kadangi visų komponentų sąveika vyksta per šią sąsają, sąveika su įvairiomis paslaugomis yra labai paprasta. Sąsaja yra ta pati! Tai taip pat reiškia, kad įgyvendinimo pokyčiai gali būti atliekami atskirai. Tokie pokyčiai neturės įtakos pagrindinių komponentų sąveikai, nes vienoda sąsaja visada lieka tokia pati. Vienas iš trūkumų yra tas, kad esate įstrigę sąsajoje. Jei optimizavimas gali būti teikiamas konkrečiai paslaugai keičiant sąsają, nesisekė, nes „REST“ tai neigia. Tačiau ryškioje pusėje REST yra optimizuotas internetui, todėl neįtikėtinas populiarumas REST per HTTP!

Pirmiau minėtos sąvokos yra REST charakteristikos ir išskiria REST architektūrą nuo kitų architektūrų, pvz., Interneto paslaugų. Naudinga pažymėti, kad „REST“ paslauga yra žiniatinklio paslauga, tačiau žiniatinklio paslauga nebūtinai yra „REST“ paslauga.

Jei norite gauti daugiau informacijos apie REST ir pirmiau išvardytas kulkas, peržiūrėkite šį dienoraščio įrašąREST Design Principles “.

EDIT: atnaujinkite turinį pagal komentarus

207
10 нояб. atsakymas pateikiamas cmd 10 lapkričio. 2013-11-10 02:19 '13, 2:19, 2013-11-10 02:19

SOAP ( paprasto objekto prieigos protokolas ) ir „REST“ („ View State Transfer“ ) yra abu gražūs. Todėl aš jų nepalyginu, o bandau vaizduoti vaizdą, kai norėčiau naudoti REST ir SOAP.

Kas yra naudingoji apkrova?

Kai duomenys perduodami internetu, kiekvienas perduotas blokas apima ir antraštės informaciją, ir faktinius siunčiamus duomenis. Antraštė nurodo paketo šaltinį ir paskirties vietą, o faktiniai duomenys vadinami naudinguoju krūviu . Apskritai naudingoji apkrova yra duomenys, perduodami programos vardu ir duomenys, gaunami pagal paskirties sistemą.

Dabar, pavyzdžiui, turiu siųsti telegramą , ir mes visi žinome, kad telegramos kaina priklausys nuo žodžių skaičiaus.

Taigi pasakykite man tarp žemiau nurodytų dviejų pranešimų, kurie yra pigesni siųsti?

 <name>Arin</name> 

arba

 "name": "Arin" 

Žinau, kad jūsų atsakymas bus antras, nors abu - tai pats antrasis pranešimas - yra pigesni sąnaudų atžvilgiu.

Taigi, bandau pasakyti, kad duomenų siuntimas tinkle Json formatu yra pigesnis nei siuntimas Xml formatu naudingosios apkrovos požiūriu .

Čia yra pirmasis privalumas arba privalumai REST per SOAP . SOAP palaiko tik XML, bet REST palaiko įvairius formatus, pvz., Tekstą, JSON, XML ir kt. Ir mes jau žinome, kad jei mes naudosime Jsoną, tai tikrai bus geriausioje vietoje naudingumo atžvilgiu.

Dabar SOAP palaiko tik XML, tačiau jis taip pat turi savo privalumų.

Tikrai! Kaip?

SOAP remiasi XML trimis būdais: Vokas - nustato, kas yra pranešime ir kaip jį tvarkyti.

Duomenų tipų kodavimo taisyklių rinkinys ir, galiausiai, procedūrų kvietimų ir atsakymų išdėstymas.

Šis vokas siunčiamas per transportą (HTTP / HTTPS), o RPC (nuotolinio procedūrų kvietimas) vykdomas, o vokas grąžinamas su informacija XML dokumente.

Svarbu pabrėžti, kad vienas iš SOAP privalumų yra „bendrinis“ < , bet REST naudoja HTTP / HTTPS , SOAP gali naudoti beveik bet kokį transportą, kad išsiųstų užklausą, bet REST negali. Taigi čia mes turime privalumą naudoti SOAP.

Kaip minėjau ankstesnėje pastraipoje, „REST naudoja HTTP / HTTPS“ , todėl būkite giliau šiuose žodžiuose.

Kai kalbame apie REST per HTTP, visos naudojamos HTTP saugumo priemonės yra paveldėtos, ir tai vadinama transporto lygio saugumu , ir ji apsaugo tik pranešimus, jei ji yra stipri>, bet kai jūs ją pristatysite iš kitos pusės, iš tikrųjų jūs nežinote, kiek etapų turite pereiti prieš pasiekdami tikrąjį tašką, kuriame duomenys bus tvarkomi. Ir, žinoma, visi šie etapai gali naudoti kažką kitą, nei HTTP. Taigi, poilsis nėra saugesnis, ar ne?

Tačiau „SOAP“ palaiko SSL , kaip ir „ REST“ , taip pat palaiko „WS-Security“ , kuri papildo kai kurias įmonės saugos funkcijas. „WS-Security“ suteikia apsaugą nuo pranešimo kūrimo prieš jį suvartojant . Taigi saugumo lygiui saugumo lygmeniu, nepaisant spragų, kurias mes randame, jį galima išvengti naudojant WS-Security.

Be to, kadangi REST apsiriboja HTTP protokolu , jo operacijų palaikymas neatitinka ACID reikalavimų ir negali suteikti dviejų fazių įsipareigojimo per paskirstytus tarptautinius išteklius.

Tačiau SOAP turi visapusišką paramą tiek ACID pagrindu veikiantiems sandoriams valdyti, tiek trumpalaikiams sandoriams, ir kompensacijomis pagrįstam sandorių valdymui ilgalaikiams sandoriams. Ji taip pat remia dvifazį priėmimą per paskirstytus išteklius .

Nėra jokių išvadų, bet aš tikrai norėčiau naudoti SOAP pagrįstą žiniatinklio paslaugą, o saugumo, sandorio ir pan. yra pagrindiniai klausimai.

Čia yra „Java EE 6 Tutorial“, kuriame teigiama, kad „ RESTful Design“ gali būti svarbi, jei tenkinamos šios sąlygos . Pažvelkite.

Tikiuosi, kad jums patiko skaityti mano atsakymą.

158
14 июня '15 в 22:48 2015-06-14 22:48 atsakymas pateikiamas Bikui birželio 15 d. 15 val. 10.48 val. 2015-06-14 22:48

SOAP ir REST žiniatinklio paslaugos

Yra daug skirtumų tarp SOAP ir REST žiniatinklio paslaugų. Toliau pateikiami svarbūs 10 skirtumai tarp SOAP ir REST:

  • SOAP yra protokolas . REST yra architektūrinis stilius .
  • SOAP reiškia „ Simple Object Access Protocol“ . „REST“ reiškia valstybinį perkėlimą .
  • SOAP negali naudoti REST, nes tai protokolas. REST gali naudoti SOAP žiniatinklio paslaugas, nes tai yra koncepcija ir gali naudoti bet kurį protokolą, pvz., HTTP, SOAP.
  • SOAP naudoja paslaugų sąsajas verslo logikai atskleisti . REST naudoja URI, kad atskleistų verslo logiką .
  • Java JAX-WS naudoja Java API SOAP žiniatinklio paslaugoms. „Java“ sistemoje JAX-RS yra „Java“ API atnaujinamoms interneto paslaugoms.
  • SOAP apibrėžia standartus, kurie yra griežtai vykdomi. REST neapibrėžia per daug standartų, pvz., SOAP.
  • SOAP reikia daugiau pralaidumo ir išteklių nei REST. REST reikalauja mažiau pralaidumo ir išteklių nei SOAP.
  • SOAP apibrėžia savo saugumą . Atgalinės interneto paslaugos paveldi saugumo priemones iš pagrindinio transporto.
  • SOAP leidžia tik XML duomenų formatą . REST leidžia naudoti kitą duomenų formatą , pvz., Paprastą tekstą, HTML, XML, JSON ir kt.
  • SOAP yra mažiau pageidaujamas nei REST. REST yra pirmenybė prieš SOAP.
87
15 марта '16 в 11:27 2016-03-15 11:27 atsakymas duotas Charan Ghate kovo 15, 16, 11:27 2016-03-15 11:27

REST ( RE pristatymas „ S tate T ransfer“)
REST yra architektūrinis stilius. Ji neapibrėžia tokių standartų kaip SOAP. „REST“ skirtas viešam API skelbimui, skirtam CRUD duomenų operacijoms apdoroti. „REST“ yra orientuota į prieigą prie pavadintų išteklių per vieną nuoseklią sąsają.

„SOAP“ („ S“ diegimas „ O cject A ccess Protocol“) - SOAP atneša savo protokolą ir orientuojasi į taikymo logikos dalių (o ne duomenų) atskleidimą kaip paslaugas. SOAP teikia operacijas. SOAP yra orientuota į prieigą prie pavadintų operacijų, kurių kiekvienas įgyvendina tam tikrą verslo logiką, naudodamas įvairias sąsajas. Nors SOAP paprastai vadinama žiniatinklio paslaugomis , tai yra neteisingas pavadinimas. SOAP turi labai mažai bendro su internetu. REST teikia tikrąsias interneto paslaugas, pagrįstas URI ir HTTP.

Kodėl pailsėti?

  • Kadangi REST naudoja standartinį HTTP, bet kuriuo metu jis yra daug paprastesnis.
  • REST leidžia naudoti daug įvairių duomenų formatų, kai SOAP leidžia tik XML.
  • REST leidžia jums pagerinti naršyklės palaikymą naudojant JSON palaikymą.
  • „REST“ turi geresnį našumą ir mastelį. REST skaitymą galima išsaugoti talpykloje.
  • Jei saugumas nėra rimta problema, turime ribotus išteklius. Arba norime sukurti API, kuri bus lengvai naudojama kitiems kūrėjams viešai, tada mes turime eiti su REST žiniatinklio paslaugomis.
  • Jei mums reikia operacijų be CRUD.

Kodėl SOAP?

  • „WS-Security“: Nors SOAP palaiko SSL (pvz., „REST“), jis taip pat palaiko „WS-Security“, kuris papildo kai kurias įmonės saugumo funkcijas.
  • WS-AtomicTransaction: Reikalauja ACID operacijų per paslaugą, jums reikės SOAP.
  • WS-ReliableMessaging: Jei jūsų programai reikalingas asinchroninis apdorojimas ir garantuotas patikimumo ir saugumo lygis. Poilsis neturi standartinės pranešimų sistemos ir tikisi, kad klientai reaguos į ryšio triktis bandydami dar kartą.
  • SOAP yra labai saugus, nes jis apibrėžia savo saugumą.
  • Jei saugumas yra rimta problema, o ištekliai yra neriboti, privalome naudoti SOAP žiniatinklio paslaugas. Pvz., Jei sukuriame žiniatinklio paslaugą, susijusią su darbu, susijusiu su bankininkyste, mes turime eiti su SOAP, nes tam reikia aukšto saugumo.

2019

09 дек. atsakymas pateikiamas Premraj 09 dec. 2015-12-09 02:38 '15 at 2:38 2015-12-09 02:38

Sprendimas tarp šių dviejų bus jūsų pirmasis pasirinkimas kuriant internetinę paslaugą, todėl svarbu suprasti šių dviejų privalumus ir trūkumus. Taip pat svarbu, kad pūslėse diskusijose tarp dviejų filosofijų realybę galima atskirti nuo retorikos.

REST pagrindai

  • Viskas REST yra laikoma ištekliumi.
  • Kiekvienas šaltinis identifikuojamas URI.
  • Naudoja atskiras sąsajas. Ištekliai apdorojami naudojant POST, GET, PUT, DELETE operacijas, kurios yra panašios į operacijas „Create, read, update“ ir „Delete“ (CRUD).
  • Būkite be pilietybės. Kiekvienas prašymas yra nepriklausomas prašymas. Kiekviename kliento prašyme serveryje turi būti visa informacija, reikalinga užklausai suprasti.
  • Ryšiai atliekami per rodinius. Pavyzdžiui. XML, JSON RESTful žiniatinklio paslaugos RESTFul žiniatinklio paslaugos yra pagrįstos HTTP metodais ir REST koncepcijomis. RESTFul žiniatinklio paslauga paprastai apibrėžia bazinį URI paslaugų, palaikomų MIME tipų (XML, teksto, JSON, vartotojo apibrėžtų, ...) ir operacijų (POST, GET, PUT, DELETE) rinkinį, kurie yra palaikomi.

SOAP pagrindai

  • WSDL apibrėžia sutartį tarp kliento ir paslaugos ir yra statinio pobūdžio.
  • SOAP sukuria protokolą, pagrįstą XML per HTTP arba kartais TCP / IP.
  • SOAP aprašo funkcijas ir duomenų tipus.
  • SOAP yra XML-RPC perėmėjas ir yra labai panašus, tačiau apibūdina standartinį bendravimo metodą.
  • Keletas programavimo kalbų turi įmontuotą SOAP palaikymą, paprastai įkeliate žiniatinklio paslaugos URL ir galite skambinti savo interneto paslaugų funkcijoms be specialaus kodo.
  • Išsiųsti dvejetainiai duomenys pirmiausia turi būti koduojami tokiu formatu kaip bazinis64.
  • Ji turi keletą protokolų ir technologijų, susijusių su juo: WSDL, XSD, SOAP, WS-Addressing.

SOAP vs REST?

Vienas iš pagrindinių SOAP privalumų yra tai, kad turite WSDL paslaugos aprašymą. Вы можете в значительной степени обнаружить службу автоматически и создать полезный клиентский прокси из этого описания службы (сгенерировать вызовы служб, необходимые типы данных для методов и т.д.). Обратите внимание, что с версией 2.0 WSDL поддерживает все HTTP-глаголы и может использоваться для документирования служб RESTful, но для этой цели существует менее подробный вариант в WADL (>