Ar norite susieti savo programą su „Facebook“, kad ji galėtų automatiškai generuoti įrašus, ar su „Instagram“, kad galėtumėte iš naujo paskelbti nuotraukas su tam tikromis grotažymėmis?
Taip pat galite į savo svetainę įtraukti „YouTube“ vaizdo įrašų. Programų programavimo sąsajos leidžia atlikti visas šias užduotis ir dar daugiau (API).
Dėl API, pvz., Instagram API, Facebook API ir YouTube API, skirtingos programos gali „kalbėti“ viena su kita saugiai ir standartizuotu būdu.
Kitaip tariant, programa gali paimti funkcijas ar duomenis iš kitos programinės įrangos ir panaudoti juos savo funkcijoms ar naudotojo patirčiai pagerinti. Tačiau kaip programos gali pateikti šias užklausas, jas apdoroti ir atsakyti į jas taip, kad kiti galėtų suprasti?
Tai priklauso nuo to, kaip buvo sukurta API. Aptariant API (aplikacijų programavimo sąsajos) dizainą, įprasta lyginti SOAP ir REST – dvi ryškiausias API paradigmas.
Kai tik SOAP API (Simple Object Access Protocol) tapo auksiniu standartu tokioms firmoms kaip „Oracle“, „Sun“ ir „PayPal“, maždaug po metų sulaukta vienodo ir priešingo atsako į REST API iš „Google“, „Amazon“ ir „eBay“.
Šiame įraše palyginsime ir palyginsime SOAP API su REST API, kad galėtumėte nuspręsti, kuri geriausiai tinka jūsų tikslams.
Pradėsime apibrėždami API.
Kas yra API?
Programų programavimo sąsaja vadinama API. API iš esmės yra metodų ir funkcijų rinkinys, leidžiantis kurti programas. Jie gauna prieigą prie įvairių programų, paslaugų ar operacinių sistemų informacijos ir funkcijų.
Jie tarnauja kaip tarpininkas tarp įvairių programinės įrangos sistemų. Jie leidžia „kalbėti“ tarp dviejų nesusijusių programų.
Paimkime pavyzdį biržos maklerio, kuris aktyviai dalyvauja prekyboje ir finansų rinkose. Automatizuotų rinkinys prekybos algoritmai galima prisijungti prie prekybininko mėgstamos prekybos brokerių platformos per API. Tai leidžia jums, prekybininkui, atlikti elektronines operacijas arba realaus laiko kainas ir kainų duomenis matyti.
Kas yra REST?
Tikros „žiniatinklio paslaugų“ API apima REST (representational State Transfer). REST API yra sukurtos naudojant URI (vienodus išteklių identifikatorius, kurių URL yra ypatingas), HTTP protokolu ir neįtikėtinai su naršykle suderinamu JSON duomenų formatu.
SOAP protokolas, kaip jau minėjome, taip pat gali būti naudojamas. REST API gali būti lengva sukurti ir plėsti, tačiau jos taip pat gali būti didžiulės ir sudėtingos – viskas priklauso nuo to, kaip jos sukuriamos, išplečiamos ir kaip jos yra skirtos.
Išteklių apribojimai, mažesni saugos reikalavimai, naršyklės kliento suderinamumas, aptinkamumas, duomenų būklė ir mastelio keitimas yra keletas priežasčių, dėl kurių norėtumėte sukurti API, kad ji būtų RESTful – dalykai, kurie iš tikrųjų taikomi žiniatinklio paslaugoms.
REST siūlo lengvesnį variantą. SOAP buvo sunku naudoti ir daugeliui kūrėjų buvo sunku. Pavyzdžiui, naudojant SOAP su JavaScript, norint atlikti paprastas operacijas, reikia parašyti daug kodo, nes kiekvieną kartą reikia sukurti reikiamą XML struktūrą.
REST (paprastai) vietoj XML užklausos naudoja paprastą URL. Nors pasitaiko retų aplinkybių, kai reikia pateikti daugiau informacijos, dauguma RESTful žiniatinklio paslaugų naudoja tik URL techniką.
REST gali naudoti keturis HTTP 1.1 veiksmažodžius GET, POST, PUT ir DELETE, kad galėtų atlikti operacijas. Skirtingai nei SOAP, REST nereikia, kad atsakymas būtų XML.
Galimos REST pagrįstos žiniatinklio paslaugos, kurios išveda duomenis komandomis atskirtomis reikšmėmis (CSV), JavaScript Object Notation (JSON) ir Really Simple Syndication (RSS) formatais (RSS).
Tikslas yra tai, kad galite gauti reikiamus rezultatus lengvai išanalizuojamu formatu ta kalba, kurią naudojate savo programai.
Savybės
- Dėl HTTP protokolų REST visų pirma pabrėžia paprastumą.
- Internetas geriausiai tinka POILSIUI. Jis suderinamas su naršyklėmis, nes JSON naudojamas kaip duomenų formatas.
- REST yra žinomas dėl savo išskirtinio mastelio ir greičio.
- Kliento ir serverio ryšiai ir architektūros yra labiau prieinamos naudojant REST API. Jei jis yra RESTful, jis yra sukurtas naudojant šį kliento-serverio modelį, kai dvi šalys perduoda naudingus duomenis.
- REST API naudoja atskirą standartinę sąsają. Užtikrinant, kad visos programos jungtųsi tolygiai ir per tą patį šliuzą, supaprastina programų ryšį su API.
Kas yra MUILAS?
Jo paties protokolas, vadinamas SOAP (Simple Object Access Protocol), yra šiek tiek sudėtingesnis nei REST, nes nurodo daugiau standartų, įskaitant tuos, kurie susiję su saugumu ir pranešimų pristatymu.
Šios būdingos normos turi šiek tiek papildomų išlaidų. Tačiau jie gali būti lemiamas veiksnys įmonėms, kurioms reikia daugiau saugumo, operacijų ir ACID (atomumo, nuoseklumo, izoliacijos, patvarumo) atitikties galimybių.
Siekiant šio palyginimo, svarbu pažymėti, kad daugelis SOAP pranašumų dažnai netaikomi žiniatinklio paslaugų programoms, todėl jos labiau tinka įmonės tipo scenarijams.
Aukštesni saugumo laipsniai (pvz., kai a mobilioji programa bendrauja su banku), pranešimų programos, kurioms reikalingas patikimas ryšys, sąveika su senomis sistemomis arba ACID atitiktis yra kelios priežastys, dėl kurių norėtumėte sukurti programą naudojant SOAP API.
SOAP siūlomos pranešimų siuntimo galimybės yra visiškai pagrįstos XML. Senesnės su internetu nesuderinamos technologijos, tokios kaip paskirstytų komponentų objektų modelis (DCOM) ir bendrosios objektų užklausos tarpininko architektūra, buvo pakeistos SOAP, kai ją pirmą kartą sukūrė „Microsoft“ (CORBA).
Dėl dvejetainių ryšių šios sistemos sugenda. Internete XML pranešimų siuntimas, kaip naudojamas SOAP, veikia geriau.
Savybės
- SOAP saugumas yra žymiai griežtesnis. WS-Security yra integruotas standartas, siūlantis SOAP papildomas įmonės lygio saugos galimybes, jei reikia, be SSL palaikymo.
- Sėkmingas / iš naujo pabandykite argumentuoti, kad pranešimų siuntimas būtų patikimas. Kadangi REST trūksta standartizuoto pranešimų mechanizmo, jis gali bandyti iš naujo tik tada, kai nepavyksta susisiekti. Net naudojant SOAP tarpinius produktus, SOAP užtikrina visišką patikimumą dėl integruotos sėkmingo / pakartotinio bandymo logikos.
- SOAP jau atitinka ACID standartus. Diktuodamas, kaip operacijos gali sąveikauti su duomenų baze, ACID atitiktis sumažina anomalijas ir užtikrina duomenų bazės nuoseklumą. Kadangi ACID yra atsargesnis nei kiti duomenų nuoseklumo modeliai, jis dažnai naudojamas tvarkant jautrias finansines ar kitokias operacijas.
- Programuotojams tai lengva suprasti, nes SOAP yra visiškai XML pagrįsta komunikacija.
- XML pranešimų protokolas yra HTTP protokolo priedas.
- Ryšiai iš vieno kompiuterio į kitą gali būti platinami naudojant SOAP pranešimus.
- Taip pat gali būti įdiegta kliento-serverio architektūra. SOAP protokolo pranešimą klientas gali naudoti, norėdamas iškviesti nuotolinį procedūros iškvietimą, kuris yra serverio pusėje.
REST Vs SOAP skirtumai
1. architektūra
API skirta pirmiausia rodyti konkrečius serverio taikomosios programos verslo logikos komponentus. Nors REST naudoja URI tuo pačiu tikslu, SOAP tam naudoja paslaugų sąsają.
REST API sukuriamos po duomenų, o SOAP API sukuriamos pagal API iliustruojančias funkcijas. Palyginti su SOAP, kuris yra labiau pagrįstas funkcijomis, REST yra labiau duomenimis pagrįstas dizainas.
2. Spartinimas
Duomenis, kurie buvo pažymėti kaip talpinami, naršyklės gali vėl panaudoti, nereikalaudamos serveriui pateikti naujos užklausos. Tai naudinga sutaupyti laiko ir pastangų.
Atsakymai nebus saugomi HTTP lygiu, nes SOAP užklausos pateikiamos per POST užklausas, kurias HTTP standartas laiko neidempotiškomis. Jei norite naudoti talpyklą, vis tiek turite sukurti reikiamus metodus, nes REST API neapima šio diegimo.
3. Ištekliai ir pralaidumas
Dėl SOAP naudojamo voko tipo naudingosios apkrovos perdavimo šiek tiek padidėja pridėtinės išlaidos, todėl reikia papildomo pralaidumo. Tokiose situacijose lengvas REST pobūdis yra naudingas, nes jis paprastai naudojamas žiniatinklio paslaugoms.
4. Saugumas
Pageidautina WS saugumas, kurį palaiko SOAP ir kuris yra šiek tiek kruopštesnis nei SSL transportavimo lygiu. Įmonės lygio saugos priemonių įtraukimas taip pat puikiai tinka.
Visišką šifravimą naudojant SSL palaiko ir SOAP, ir REST, o REST gali naudoti HTTPS, saugų HTTP protokolo variantą.
5. Naudingųjų krovinių tvarkymas
Duomenys, perduodami internetu, vadinami naudingu kroviniu. Naudingam kroviniui, kuris laikomas „sunkiu“, reikia papildomų išteklių. Palyginti su SOAP, kuris naudoja XML, REST dažnai naudoja JSON ir HTTP, kad padėtų sumažinti naudingą apkrovą.
Klientas paprastai turi naudoti specializuotą Kliento biblioteką su sugeneruotu kodu, kad pasiektų SOAP API dėl itin griežtos ryšio sutarties.
Dėl to SOAP siūlo mažesnį abstrakcijos lygį nei REST ir yra glaudžiau susijęs su serveriu.
Kada naudoti REST?
- Viešųjų API kūrimas: REST API pirmenybė teikiama viešosioms žiniatinklio paslaugoms kurti, nes manoma, kad jas naudoti ir pritaikyti lengviau nei SOAP API. Be to, SOAP siūlo keletą integruotų saugumo priemonių, kurių REST neturi, nors šios charakteristikos nėra būtinos dirbant su atvirais duomenimis ir paslaugomis.
- Mobiliųjų programėlių kūrimas: REST puikiai tinka kurti mobiliąsias programas, nes yra maža, efektyvi, be būsenos ir talpykloje.
- Naudojant ribotus serverio išteklius ir pralaidumą: visos REST API užklausos turi būti be būsenos, o tai reiškia, kad kiekviena sąveika yra atskira ir kiekvienoje užklausoje bei atsakyme yra visi duomenys, reikalingi šiai sąveikai užbaigti. Serveris neišsaugo ankstesnių užklausų įrašų, nes kiekvieną iš jų traktuoja kaip naują užklausą. Dėl to serveriui reikia daug mažiau atminties ir jis veikia greičiau, nes užklausa nereikalauja tolesnių veiksmų ar istorinių duomenų gavimo.
Kada naudoti SOAP?
- Privačių API kūrimas, ypač didelėms įmonėms: SOAP puikiai tinka verslo programoms, nes leidžia perduoti duomenis decentralizuotoje, paskirstytoje aplinkoje ir turi keletą internetinės saugos funkcijų.
- Kaip pagrindinį sluoksnį naudoti kitokį nei HTTP transportavimo protokolą: SOAP nepriklauso nuo HTTP kaip pagrindinio sluoksnio. Priklausomai nuo programos, galite naudoti SMTP (paprastą pašto perdavimo protokolą), JMS (Java pranešimų paslaugą) arba kitą transportavimo protokolą.
- Darbas su būsenos operacijomis: Priešingai nei REST API užklausos, SOAP API užklausos yra būsenos, o tai reiškia, kad serveris išsaugo informaciją apie klientą ir naudoja ją visoje užklausų arba operacijų grandinėje. Net jei tai sunaudoja daugiau serverio pralaidumo ir išteklių, tai labai svarbu atliekant įprastinius arba susijusius veiksmus, pvz., banko pavedimus.
Išvada
Palyginus REST ir SOAP API, akivaizdu, kad REST yra geriau nei SOAP. Vis dėlto yra situacijų, kai reikalinga SOAP API. Tam tikrais atvejais žiniatinklio paslaugos sukuriamos derinant REST ir SOAP API.
Todėl naudojimo atvejis lems, kuris API stilius veiks geriausiai.
Palikti atsakymą