Seep vs. REST: Web API teenuste erinevus

Lang L: none (table-of-contents):

Anonim

Mis on seep?

SOAP on enne REST-i välja töötatud ja pildile tulnud protokoll. SOAP-i kujundamise peamine mõte oli tagada, et erinevatele platvormidele ja programmeerimiskeeltele loodud programmid saaksid hõlpsalt andmeid vahetada. SOAP tähistab lihtsat objekti juurdepääsuprotokolli.

Mis on puhkus?

REST oli mõeldud spetsiaalselt teatud riistvaraseadme komponentide, näiteks meediumikomponentide, failide või isegi objektidega töötamiseks. Iga REST-i põhimõtetel määratletud veebiteenust võib nimetada RestFuli veebiteenuseks. Rahulik teenus kasutaks vajalike komponentidega töötamiseks tavalisi HTTP-verbe GET, POST, PUT ja DELETE. REST tähistab esindusriigi üleandmist.

PÕHISED erinevused

  • SOAP tähistab lihtsat objekti juurdepääsuprotokolli, REST aga esindusriigi edastust.
  • SOAP on protokoll, REST aga arhitektuurne muster.
  • SOAP kasutab teenuseliideseid, et oma funktsionaalsus kliendirakendustele avaldada, samal ajal kui REST kasutab riistvaras olevatele komponentidele juurdepääsemiseks Uniform Service'i lokaatoreid.
  • SOAP vajab selle kasutamiseks suuremat ribalaiust, samas kui REST ei vaja palju ribalaiust.
  • SOAP töötab ainult XML-vormingutega, REST aga lihtteksti, XML-i, HTML-i ja JSON-iga.
  • SOAP ei saa kasutada REST-i, samas kui REST saab kasutada SOAP-i.

Erinevus seebi ja puhkuse vahel

Igal tehnikal on oma eelised ja puudused. Seega on alati hea mõista, millistes olukordades peaks iga kujundust kasutama. Selles õpetuses käsitletakse mõningaid peamisi erinevusi nende tehnikate vahel ning seda, milliseid väljakutseid võib nende kasutamise ajal ette tulla.

Allpool on peamised erinevused SOAP-i ja REST-i vahel

SEEP

Puhkus
  • SOAP tähistab lihtsat objekti juurdepääsuprotokolli
  • REST tähistab esindusriigi üleandmist
  • SOAP on protokoll. SOAP kujundati spetsifikatsiooniga. See sisaldab WSDL-faili, millel on lisaks veebiteenuse asukohale vajalik teave selle kohta, mida veebiteenus teeb.
  • REST on arhitektuuristiil, kus veebiteenust saab RESTful teenusena käsitleda ainult siis, kui see järgib olemise piiranguid
    1. Kliendiserver
    2. Kodakondsuseta
    3. Vahemällu salvestatud
    4. Kihiline süsteem
    5. Ühtne liides
  • SOAP ei saa REST-i kasutada, kuna SOAP on protokoll ja REST on arhitektuurne muster.
  • REST saab veebiteenuste alusprotokollina kasutada SOAP-i, sest lõppkokkuvõttes on see lihtsalt arhitektuurne muster.
  • SOAP kasutab teenuseliideseid, et oma funktsionaalsust kliendirakendustele avaldada. SOAP-i puhul annab WSDL-fail kliendile vajaliku teabe, mida saab kasutada selleks, et mõista, milliseid teenuseid veebiteenus võib pakkuda.
  • REST kasutab riistvaraseadme komponentidele juurde pääsemiseks Uniform Service'i lokaatoreid. Näiteks kui on olemas objekt, mis esindab URL-is hostitud töötaja andmeid aadressil http: //demo.guru99, on allpool toodud mõned URI-d, mis võivad nendele juurdepääsemiseks olemas olla

    • http://demo.guru99.com/töötaja

    http://demo.guru99.com/töötaja/1
  • SOAP nõuab selle kasutamiseks suuremat ribalaiust. Kuna SOAP-sõnumid sisaldavad selle sees palju teavet, on andmeedastuse maht SOAP-i abil tavaliselt palju.
int
  • REST ei vaja serverile päringute saatmisel palju ribalaiust. REST-sõnumid koosnevad enamasti lihtsalt JSON-sõnumitest. Allpool on näide JSON-sõnumist, mis edastati veebiserverile. Näete, et sõnumi suurus on SOAP-iga suhteliselt väiksem.
    • {"city":"Mumbai","state":"Maharastra"}
  • SOAP saab töötada ainult XML-vormingus. Nagu SOAP-sõnumitest nähtub, on kõik edastatud andmed XML-vormingus.
  • REST lubab erinevat andmevormingut, nagu tavaline tekst, HTML, XML, JSON jne. Kuid andmete edastamiseks on eelistatuim vorming JSON.

Millal kasutada puhkust?

Üks kõige vaieldavam teema on see, millal tuleks veebiteenuste kujundamisel kasutada REST-i või millal kasutada SOAP-i. Allpool on toodud mõned peamised tegurid, mis määravad, millal iga tehnoloogiat tuleks veebiteenuste jaoks kasutada. REST-teenuseid tuleks kasutada järgmistel juhtudel

  • Piiratud ressursid ja ribalaius - kuna SOAP-sõnumid on sisult raskemad ja kulutavad palju suuremat ribalaiust, tuleks REST-i kasutada juhtudel, kui võrgu ribalaius on piirang.

  • Kodakondsusetus - kui puudub vajadus säilitada teavet ühest taotlusest teise, tuleks kasutada REST. Kui vajate korralikku teabevoogu, kus osa päringutest pärinevat teavet peab liikuma teise, on SOAP selleks otstarbeks sobivam. Võime võtta näite mis tahes veebipõhistest ostusaitidest. Nendel saitidel on tavaliselt vaja, et kasutaja lisaks ostukorvi üksused, mis tuleb osta. Seejärel kantakse kõik ostukorvi üksused ostu lõpuleviimiseks makselehele. See on näide rakendusest, mis vajab olekutunnust. Ostukorvi üksuste olek tuleb edasiseks töötlemiseks üle kanda makselehele.

  • Vahemällu salvestamine - kui on vaja vahemällu salvestada palju taotlusi, on REST ideaalne lahendus. Mõnikord said kliendid sama ressurssi mitu korda taotleda. See võib suurendada serverisse saadetud päringute arvu. Vahemälu juurutades saab kõige sagedasemad päringute tulemused salvestada vahekohta. Nii et kui klient taotleb ressurssi, kontrollib ta kõigepealt vahemälu. Kui ressursid on olemas, ei liigu see serverisse. Seega võib vahemällu salvestamine aidata veebiserverisse tehtavate reiside arvu minimeerida.

  • Kodeerimise lihtsus - REST-teenuste kodeerimine ja hilisem juurutamine on palju lihtsam kui SOAP. Nii et kui veebiteenuste jaoks on vaja kiiret võidulahendust, siis on selleks REST.

Millal kasutada seepi?

SOAP-i tuleks kasutada järgmistel juhtudel

  1. Asünkroonne töötlemine ja sellele järgnev kutsumine - kui on nõue, et klient vajab tagatud usaldusväärsuse ja turvalisuse taset, pakub SOAP 1.2 uus SOAP-standard palju täiendavaid funktsioone, eriti turvalisuse osas.

  2. Ametlik sidevahend - kui nii kliendil kui serveril on vahetusvormingu osas kokkulepe, annab SOAP 1.2 seda tüüpi suhtlusele jäigad spetsifikatsioonid. Näide on veebipõhine ostusait, kus kasutajad lisavad enne makse sooritamist ostukorvi tooteid. Oletame, et meil on veebiteenus, mis teeb lõppmakse. Võib olla kindel kokkulepe, et veebiteenus aktsepteerib ainult ostukorvi nime, ühikuhinda ja kogust. Kui selline stsenaarium on olemas, on alati parem kasutada SOAP-protokolli.

  3. Olekukujulised toimingud - kui rakendusel on nõue, et olekut tuleb säilitada ühest taotlusest teise, pakub SOAP 1.2 standard selliste nõuete toetamiseks WS * struktuuri.

Väljakutsed SOAP API-s

API on tuntud kui Application Programming Interface ja seda pakuvad nii klient kui server. Kliendimaailmas pakub seda brauser, samas kui serverimaailmas pakub seda veebiteenus, mis võib olla kas SOAP või REST.

Väljakutsed SOAP API-ga

  1. WSDL-fail - SOAP API üks peamisi väljakutseid on WSDL-dokument ise. WSDL-dokument on see, mis ütleb kliendile kõiki toiminguid, mida veebiteenus saab teha. WSDL-dokument sisaldab kogu teavet, näiteks SOAP-sõnumites kasutatavaid andmetüüpe ja kõiki toiminguid, mis on veebiteenuse kaudu saadaval. Allpool olev koodilõik on vaid osa WSDL-faili näidisest.

Nagu ülaltoodud WSDL-failis, on meil element nimega "TutorialName", mis on tüüpi String, mis on osa elemendist TutorialNameRequest.

Oletame, et kui WSDL-fail peaks muutuma vastavalt ärinõuetele ja TutorialName peaks saama TutorialDescription. See tähendaks, et kõik kliendid, kes praegu selle veebiteenusega ühendust loovad, peavad WSDL-failis tehtud muudatuste mahutamiseks oma koodis vastava muudatuse tegema.

See näitab WSDL-faili suurimat väljakutset, milleks on tihe leping kliendi ja serveri vahel ning et üks muudatus võib tervikuna kliendirakendustele suurt mõju avaldada.

  1. Dokumendi suurus - Teine peamine väljakutse on SOAP-sõnumite suurus, mis edastatakse kliendilt serverisse. Suurte sõnumite tõttu võib SOAP-i kasutamine kohtades, kus ribalaius on piirang, olla suur probleem.

REST API väljakutsed

  1. Turvalisuse puudumine - REST ei kehtesta mingit tüüpi turvalisust nagu SOAP. Seetõttu on REST avalikele URL-idele väga sobiv, kuid kui tegemist on kliendi ja serveri vahel konfidentsiaalsete andmete edastamisega, on REST halvim veebiteenuste jaoks kasutatav mehhanism.
  2. Riigi puudumine - enamik veebirakendusi nõuab olekumehhanismi. Näiteks kui teil oli ostusait, millel oli ostukorvi omamise mehhanism, peab enne ostu sooritamist teadma ostukorvis olevate toodete arvu. Kahjuks lasub selle oleku säilitamise koorem kliendil, mis muudab kliendirakenduse lihtsalt raskemaks ja raskesti hooldatavaks.

Erinevus SOAP Vs CORBA vs DCOM Vs Java RMI vahel

Kaugjuurdepääsu tehnikad, näiteks RPC (kaugprotseduuride väljakutsed) meetodid, olid levinud juba enne SOAPi ja RESTi tulekut. Allpool on nimetatud erinevad kättesaadavad kaugjuurdepääsu tehnikad.

  1. CORBA - See oli tuntud C sisaldab ühisele O bject R equest B Roker rchitecture. See süsteem pandi paika tagamaks, et erinevatele platvormidele ehitatud rakendused saaksid omavahel rääkida. CORBA põhines küll objektorienteeritud arhitektuuril, kuid kutsungirakendus ei pidanud sellel arhitektuuril põhinema. Selle tehnika peamine puudus oli see, et see tuleb välja töötada eraldi keeles, mida nimetatakse liidese määratluse keeleks, ja see esitas lihtsalt lisakeele, mille arendajad pidid CORBA süsteemi kasutamiseks õppima.

  2. DCOM - See on D istributed C Märgil O bject M odel, mis on patenteeritud Microsoft tehnoloogia klientidele juurdepääsu serveri komponente. Selle mehhanismi suurim probleem oli ressursside vabastamine kliendi rakendusel, kui seda enam ei vajata.

    Teiseks, kui klient päringu saatis, oli kliendi ülesanne tagada, et päring oleks õigesti pakitud või koostatud, et veebiteenus saaks saadetud päringust aru. Teine probleem oli see, kas kliendirakendus oli Java-põhine rakendus, mis pidi töötama DCOM-is (Microsofti tehnoloogia). Selleks, et teistes programmeerimiskeeltes ehitatud rakendused saaksid töötada DCOM-i põhiste veebiteenustega, oli vaja täiendavat kodeerimist.

  3. Java RMI - Tuntud Java R emote M eetod I nvocation, see oli Java rakendamise kohta, kuidas kauge objektid võiks nimetada roonilistes korras kõned. Selle tehnoloogia suurim piirang oli see, et Java RMI-d sai käivitada ainult Java virtuaalsel masinal. See tähendas, et Java RMI kasutamiseks tuleb kutsuvat rakendust käivitada ka Java raamistikus.

Peamised erinevused SOAP-i ja nende tehnikate vahel on järgmised

  1. HTTP-ga töötamine - kõigil RPC-meetoditel on üks suur piirang ja see, et nad ei tööta HTTP-protokolli abil. Kuna kõik veebis olevad rakendused pidid selle protokolliga töötama, oli see varem suur takistus klientidele, kes pidid neile RPC-stiilis veebiteenustele juurde pääsema.
  2. Mittestandardsete pordidega töötamine - Kuna RPC-stiilis veebiteenused ei töötanud HTTP-protokolli abil, pidid nende jaoks olema avatud erinevad pordid, et kliendid saaksid nende veebiteenuste funktsionaalsusele juurde pääseda.