MILO Vs. REST: Razlika med storitvami spletnega API-ja

Kazalo:

Anonim

Kaj je milo

SOAP je protokol, ki je bil zasnovan pred REST in se je pojavil v sliki. Glavna ideja oblikovanja SOAP je bila zagotoviti, da si lahko programi, zgrajeni na različnih platformah in programskih jezikih, na enostaven način izmenjujejo podatke. SOAP pomeni Simple Object Access Protocol.

Kaj je REST?

REST je bil zasnovan posebej za delo s komponentami, kot so predstavnostne komponente, datoteke ali celo predmeti na določeni strojni napravi. Vsako spletno storitev, ki je definirana po načelih REST, lahko imenujemo spletna storitev RestFul. Storitev Restful bi za delo z zahtevanimi komponentami uporabljala običajne glagole HTTP GET, POST, PUT in DELETE. REST pomeni reprezentativni državni prenos.

KLJUČNA RAZLIKA

  • SOAP je kratica za protokol enostavnega dostopa do objektov, medtem ko REST pomeni prenos reprezentativne države.
  • SOAP je protokol, medtem ko je REST arhitekturni vzorec.
  • SOAP uporablja servisne vmesnike, da izpostavi svojo funkcionalnost odjemalskim aplikacijam, medtem ko REST uporablja enotne lokatorje storitev za dostop do komponent na strojni napravi.
  • SOAP za svojo uporabo potrebuje več pasovne širine, medtem ko REST ne potrebuje veliko pasovne širine.
  • SOAP deluje samo z formati XML, medtem ko REST deluje z navadnim besedilom, XML, HTML in JSON.
  • SOAP ne more uporabljati REST, medtem ko REST lahko uporablja SOAP.

Razlika med SOAP in REST

Vsaka tehnika ima svoje prednosti in slabosti. Zato je vedno dobro razumeti, v katerih situacijah je treba uporabiti posamezen dizajn. V tej vadnici boste našli nekaj ključnih razlik med temi tehnikami in izzive, s katerimi se lahko srečate med njihovo uporabo.

Spodaj so glavne razlike med SOAP in REST

MILO

POČITEK
  • SOAP pomeni Simple Object Access Protocol
  • REST pomeni reprezentativni državni prenos
  • SOAP je protokol. SOAP je bil zasnovan s specifikacijami. Vključuje datoteko WSDL, ki vsebuje potrebne informacije o tem, kaj spletna storitev počne poleg lokacije spletne storitve.
  • REST je arhitekturni slog, v katerem je spletno storitev mogoče obravnavati kot RESTful storitev le, če sledi omejitvam
    1. Odjemalski strežnik
    2. Brez državljanstva
    3. Predpomnilnik
    4. Večplastni sistem
    5. Enotni vmesnik
  • SOAP ne more uporabiti REST, ker je SOAP protokol, REST pa je arhitekturni vzorec.
  • REST lahko uporabi SOAP kot osnovni protokol za spletne storitve, saj je na koncu le arhitekturni vzorec.
  • SOAP uporablja servisne vmesnike za izpostavljanje svojih funkcij odjemalskim aplikacijam. V SOAP-u datoteka WSDL stranki zagotavlja potrebne informacije, s katerimi lahko razume, katere storitve lahko ponuja spletna storitev.
  • REST uporabljajte enotne lokatorje storitev za dostop do komponent na strojni napravi. Če na primer obstaja objekt, ki predstavlja podatke zaposlenega, ki gostuje na URL-ju kot http: //demo.guru99, so spodaj nekateri URI, ki lahko obstajajo za dostop do njih.

    • http://demo.guru99.com/Zaposleni

    http://demo.guru99.com/E Employee/1
  • SOAP za uporabo potrebuje več pasovne širine. Ker sporočila SOAP vsebujejo veliko informacij, je količina prenosa podatkov z uporabo SOAP na splošno velika.
int
  • REST pri pošiljanju zahtev na strežnik ne potrebuje veliko pasovne širine. Sporočila REST so večinoma sestavljena iz sporočil JSON. Spodaj je primer sporočila JSON, posredovanega spletnemu strežniku. Vidite lahko, da je velikost sporočila sorazmerno manjša od SOAP.
    • {"city":"Mumbai","state":"Maharastra"}
  • SOAP lahko deluje samo v obliki XML. Kot je razvidno iz sporočil SOAP, so vsi posredovani podatki v obliki XML.
  • REST dovoljuje drugačno obliko zapisa podatkov, kot so navadno besedilo, HTML, XML, JSON itd. Najbolj zaželena oblika za prenos podatkov pa je JSON.

Kdaj uporabiti REST?

Ena izmed najbolj diskutabilnih tem je, kdaj je treba pri načrtovanju spletnih storitev uporabiti REST ali kdaj SOAP. Spodaj je nekaj ključnih dejavnikov, ki določajo, kdaj je treba vsako tehnologijo uporabiti za spletne storitve. Storitve REST je treba uporabljati v naslednjih primerih

  • Omejeni viri in pasovna širina - Ker so sporočila SOAP vsebinsko težja in porabijo veliko večjo pasovno širino, je treba REST uporabiti v primerih, ko je pasovna širina omrežja ovira.

  • Apatridnost - če ni treba vzdrževati stanja informacij od ene zahteve do druge, potem je treba uporabiti REST. Če potrebujete ustrezen pretok informacij, pri katerem se morajo nekatere informacije iz ene zahteve preliti v drugo, je SOAP za to bolj primeren. Vzamemo lahko primer katerega koli spletnega mesta za nakup. Običajno mora ta spletna stran uporabnika najprej dodati v košarico izdelke, ki jih je treba kupiti. Nato se vsi predmeti košarice prenesejo na stran za plačilo, da dokončate nakup. To je primer aplikacije, ki potrebuje funkcijo stanja. Stanje kosov košarice je treba prenesti na stran za plačilo za nadaljnjo obdelavo.

  • Predpomnjenje - če je treba veliko zahtev shraniti v predpomnilnik, je REST odlična rešitev. Včasih so stranke lahko večkrat zahtevale isti vir. To lahko poveča število zahtev, poslanih strežniku. Z uporabo predpomnilnika lahko rezultate najpogostejših poizvedb shranite na vmesnem mestu. Torej, kadar odjemalec zahteva vir, bo najprej preveril predpomnilnik. Če viri takrat obstajajo, se strežnik ne bo nadaljeval. Tako lahko predpomnjenje pomaga pri zmanjševanju števila potovanj do spletnega strežnika.

  • Enostavnost kodiranja - kodiranje REST Services in kasnejša izvedba je veliko lažja kot SOAP. Če je torej za spletne storitve potrebna hitra rešitev, je REST prava pot.

Kdaj uporabiti SOAP?

SOAP je treba uporabljati v naslednjih primerih

  1. Asinhrona obdelava in poznejši klic - če stranka zahteva zajamčeno raven zanesljivosti in varnosti, potem novi standard SOAP 1.2 ponuja veliko dodatnih funkcij, zlasti kar zadeva varnost.

  2. Formalno sredstvo komunikacije - če se odjemalec in strežnik dogovorita o formatu izmenjave, potem SOAP 1.2 poda toge specifikacije za to vrsto interakcije. Primer je spletno nakupovalno mesto, na katerem uporabniki pred plačilom dodajo predmete v košarico. Predpostavimo, da imamo spletno storitev, ki opravi končno plačilo. Lahko se trdno dogovorimo, da bo spletna storitev sprejela samo ime artikla košarice, ceno na enoto in količino. Če takrat obstaja tak scenarij, je vedno bolje uporabiti protokol SOAP.

  3. Operacije s stanjem - če ima aplikacija zahtevo, da je treba stanje vzdrževati od ene zahteve do druge, potem standard SOAP 1.2 zagotavlja strukturo WS * za podporo takšnim zahtevam.

Izzivi v SOAP API

API je znan kot vmesnik za programiranje aplikacij in ga ponujata tako odjemalec kot strežnik. V svetu odjemalcev to ponuja brskalnik, medtem ko je v svetu strežnikov tisto, kar ponuja spletna storitev, lahko SOAP ali REST.

Izzivi s SOAP API

  1. Datoteka WSDL - Eden ključnih izzivov SOAP API je sam dokument WSDL. Dokument WSDL je tisto, kar naročniku pove vse operacije, ki jih lahko izvede spletna storitev. Dokument WSDL bo vseboval vse informacije, kot so tipi podatkov, ki se uporabljajo v sporočilih SOAP, in vse operacije, ki so na voljo prek spletne storitve. Spodnji delček kode je le del vzorčne datoteke WSDL.

Glede na zgornjo datoteko WSDL imamo element, imenovan "TutorialName", ki je tipa String, ki je del elementa TutorialNameRequest.

Recimo, da bi se datoteka WSDL spremenila v skladu s poslovnimi zahtevami, TutorialName pa mora postati TutorialDescription. To bi pomenilo, da bi potem morali vsi odjemalci, ki se trenutno povezujejo s to spletno storitvijo, ustrezno spremeniti svojo kodo, da bi se prilagodili spremembi v datoteki WSDL.

To kaže na največji izziv datoteke WSDL, ki je tesna pogodba med odjemalcem in strežnikom in da bi lahko ena sprememba močno vplivala na odjemalske aplikacije.

  1. Velikost dokumenta - Drugi ključni izziv je velikost sporočil SOAP, ki se prenesejo od odjemalca na strežnik. Zaradi velikih sporočil je uporaba SOAP-a tam, kjer je pasovna širina omejena, lahko velika težava.

Izzivi v API-ju REST

  1. Pomanjkanje varnosti - REST ne nalaga nobene vrste varnosti, kot je SOAP. Zato je REST zelo primeren za javno dostopne URL-je, toda ko gre za zaupne podatke, ki se posredujejo med odjemalcem in strežnikom, je REST najslabši mehanizem, ki se uporablja za spletne storitve.
  2. Pomanjkanje stanja - Večina spletnih aplikacij zahteva mehanizem s stanjem . Če ste imeli na primer spletno mesto za nakup, ki je imelo mehanizem nakupovalne košarice, morate pred dejanskim nakupom vedeti število kosov v nakupovalni košarici. Na žalost breme vzdrževanja tega stanja leži na odjemalcu, kar samo otežuje in otežuje vzdrževanje odjemalske aplikacije.

Razlika med SOAP Vs CORBA Vs DCOM Vs Java RMI

Tehnike oddaljenega dostopa, kot so metode RPC (oddaljeni postopki), so bile v navadi, preden sta se pojavila SOAP in REST. Spodaj so omenjene različne razpoložljive tehnike oddaljenega dostopa.

  1. CORBA - To je znano kot C KUPNA O bject R equest B Roker A rchitecture. Ta sistem je bil vzpostavljen za zagotovitev, da se lahko aplikacije, zgrajene na različnih platformah, med seboj pogovarjajo. CORBA je temeljila na objektno usmerjeni arhitekturi, vendar ni bilo potrebno, da klicna aplikacija temelji na tej arhitekturi. Glavna pomanjkljivost te tehnike je bila, da jo je treba razviti v ločenem jeziku, imenovanem Interface Definition Language, in je pravkar predstavila dodaten jezik, ki so se ga morali razviti razvijalci za uporabo sistema CORBA.

  2. DCOM - To je D porazdelijo C okviru komponente O bject M odel, ki je lastniški Microsoftovo tehnologijo za stranke za dostop do oddaljenih delov. Največja težava tega mehanizma je bila, da mora odjemalska aplikacija sprostiti vire, ko jih ni več treba.

    Drugič, ko je stranka poslala zahtevo, je morala stranka zagotoviti, da je bila zahteva pravilno ovita ali preurejena, da bo spletna storitev razumela poslano zahtevo. Druga težava je bila, ali je bila odjemalska aplikacija aplikacija na osnovi Jave, ki je morala delovati z DCOM (Microsoft Technology). Potrebno je bilo dodatno kodiranje, da se zagotovi, da lahko aplikacije, zgrajene v drugih programskih jezikih, delujejo s spletnimi storitvami na osnovi DCOM.

  3. Java RMI - Znan kot Java R poosebljanje M Metoda I nvocation, je bila ta izvedba Java, kako oddaljeni predmeti se lahko imenuje prek oddaljenih postopek klice. Največja omejitev te tehnologije je bila, da je bilo mogoče Java RMI izvajati samo na Java Virtual Machine. To je pomenilo, da je treba klicno aplikacijo zagnati tudi v okolju Java, da lahko uporabite Java RMI.

Glavne razlike med SOAP in temi tehnikami so naslednje

  1. Delo prek HTTP - Vse tehnike RPC imajo eno veliko omejitev, in sicer, da ne delujejo po protokolu HTTP. Ker so morale vse spletne aplikacije delovati po tem protokolu, je bil to včasih glavna ovira za stranke, ki so morale dostopati do teh spletnih storitev v obliki RPC.
  2. Delo z nestandardnimi vrati - Ker spletne storitve v slogu RPC niso delovale po protokolu HTTP, so jim morali biti odprti ločeni vrati, da lahko stranke dostopajo do funkcij teh spletnih storitev.