Kas soovite linkida oma rakenduse Facebookiga, et see saaks automaatselt postitusi luua, või Instagramiga, et saaksite teatud hashtagidega fotosid uuesti postitada?
Samuti võite soovida oma veebisaidile lisada YouTube'i videoid. Rakenduse programmeerimisliidesed võimaldavad teil täita kõiki neid ülesandeid ja palju muud (API-d).
Tänu API-dele, nagu Instagram API, Facebook API ja YouTube API, saavad erinevad rakendused üksteisega turvaliselt ja standardiseeritud viisil "vestelda".
Teisisõnu võib programm võtta funktsioone või andmeid mõnest teisest tarkvaraosast ja kasutada neid oma funktsioonide või kasutuskogemuse parandamiseks. Kuid kuidas saavad rakendused neid taotlusi esitada, neid töödelda ja neile teistele arusaadaval viisil vastata?
See sõltub sellest, kuidas API loodi. API (rakenduse programmeerimisliidese) kujunduste arutamisel on tavaline võrrelda SOAP-i ja REST-i, kahte silmapaistvamat API paradigmat.
Niipea, kui SOAP API-d (Simple Object Access Protocol) said kuldstandardiks sellistes ettevõtetes nagu Oracle, Sun ja PayPal, reageeris umbes aasta hiljem Google, Amazon ja eBay REST API-dele võrdne ja vastupidine reaktsioon.
Selles postituses võrdleme ja vastandame SOAP API-sid REST API-dega, et saaksite otsustada, milline on teie eesmärkide jaoks parim.
Alustuseks määratleme API.
Mis on API?
Rakenduse programmeerimisliidest nimetatakse API-ks. API-d on sisuliselt meetodite ja funktsioonide kogum, mis võimaldavad rakendusi arendada. Nad saavad juurdepääsu erinevate programmide, teenuste või operatsioonisüsteemide teabele ja funktsioonidele.
Need toimivad omamoodi vahendajana erinevate tarkvarasüsteemide vahel. Need võimaldavad "rääkimist" kahe ühendamata programmi vahel.
Võtame näiteks börsimaakleri, kes tegeleb aktiivselt kauplemise ja finantsturgudega. Automatiseeritud kogumik kauplemisalgoritmid saab API kaudu ühendada kaupleja lemmikkauplemisvahendaja platvormiga. See võimaldab teil, kauplejal, sooritada elektroonilisi tehinguid või näha reaalajas noteeringuid ja hinnaandmeid.
Mis on REST?
Tõelised „veebiteenuste” API-d hõlmavad REST-i (esindusoleku ülekanne). REST API-d on üles ehitatud URI-dele (ühtsed ressursiidentifikaatorid, mille URL on eriliik), HTTP-protokollile ja uskumatult brauseriga ühilduvale JSON-i andmevormingule.
Nagu me juba ütlesime, võidakse kasutada ka SOAP-protokolli. REST API-sid võib olla lihtne luua ja kasvatada, kuid need võivad olla ka tohutud ja keerulised – kõik sõltub sellest, kuidas neid luuakse, laiendatakse ja milleks need on mõeldud.
Ressursipiirangud, vähendatud turbenõuded, brauseri kliendi ühilduvus, leitavus, andmete seisund ja skaleeritavus on mõned põhjused, miks soovite API-d välja töötada, et see oleks RESTful – asjad, mis tegelikult kehtivad veebiteenuste puhul.
REST pakub kergemat varianti. SEEPI oli raske kasutada ja see oli paljudele arendajatele koormav. Näiteks SOAP-i kasutamine JavaScriptiga nõuab lihtsate toimingute tegemiseks palju koodi kirjutamist, kuna vajalik XML-struktuur tuleb luua iga kord.
REST kasutab (tavaliselt) XML-päringu asemel otsest URL-i. Kuigi harvadel juhtudel peate pakkuma rohkem üksikasju, kasutab enamik RESTfuli veebiteenuseid ainult URL-i tehnikat.
REST saab toimingute tegemiseks kasutada nelja HTTP 1.1 verbi GET, POST, PUT ja DELETE. Erinevalt SOAP-ist ei pea REST vastust XML-is.
Saadaval on REST-põhised veebiteenused, mis väljastavad andmeid käskudega eraldatud väärtuse (CSV), JavaScript Object Notation (JSON) ja Really Simple Syndication (RSS) vormingus (RSS).
Eesmärk on, et saate soovitud tulemused hõlpsasti sõelutavas vormingus keeles, mida oma rakenduse jaoks kasutate.
FUNKTSIOONID
- REST rõhutab HTTP-protokollide tõttu eelkõige lihtsust.
- Veeb sobib kõige paremini Puhkamiseks. See ühildub brauseritega, kuna andmevorminguna kasutatakse JSON-i.
- REST on tuntud oma silmapaistva mastaapsuse ja kiiruse poolest.
- Kliendi-serveri ühendused ja arhitektuurid muudavad REST API-de abil juurdepääsetavamaks. Kui see on RESTful, on see konstrueeritud selle klient-serveri mudeli abil, kusjuures kahe osapoole vahelised edasi-tagasi reisid edastavad andmekoormust.
- REST API-d kasutavad üksikut standardliidest. Kõigi rakenduste ühtse ühenduse ja sama lüüsi kaudu ühendamise tagamine muudab rakenduste API-ga suhtlemise sujuvamaks.
Mis on SEEP?
Selle enda protokoll, mida nimetatakse SOAP-iks (Simple Object Access Protocol), on pisut keerulisem kui REST, kuna see määrab rohkem standardeid, sealhulgas turvalisuse ja sõnumite edastamisega seotud standardeid.
Nende loomulike normidega kaasnevad veidi lisakulud. Siiski võivad need olla otsustavaks teguriks ettevõtetele, kes vajavad ulatuslikumaid turbe-, tehingu- ja ACID-i (atomilisus, järjepidevus, isolatsioon, vastupidavus) vastavust.
Selle võrdluse huvides on oluline märkida, et paljud SOAP-i eelised ei kehti sageli veebiteenuste rakenduste puhul, mistõttu need sobivad paremini ettevõtte tüüpi stsenaariumide jaoks.
Kõrgem turvalisus (nt kui a mobiilirakendusega suhtleb pangaga), sõnumsiderakendused, mis nõuavad usaldusväärset suhtlust, suhtlemine pärandsüsteemidega või ACID-i vastavus on mõned põhjused, miks soovite SOAP API-d kasutava rakenduse kujundada.
SOAP-i pakutavad sõnumiedastusvõimalused põhinevad täielikult XML-il. Vanemad Internetiga mitteühilduvad tehnoloogiad, nagu Distributed Component Object Model (DCOM) ja Common Object Request Broker Architecture, asendati SOAP-iga, kui selle esmakordselt lõi Microsoft (CORBA).
Toetumine binaarsuhtlusele põhjustab nende süsteemide ebaõnnestumise. Interneti kaudu toimib XML-sõnumside, nagu SOAP-i kasutatav, paremini.
FUNKTSIOONID
- SOAP-i turvalisus on oluliselt rangem. WS-Security on sisseehitatud standard, mis pakub vajadusel lisaks SSL-i toele SOAP-ile täiendavaid ettevõtte tasemel turbevõimalusi.
- Eduka/proovige uuesti põhjendada, et sõnumside toimivus oleks usaldusväärne. Kuna REST-il puudub standardiseeritud sõnumimehhanism, saab see uuesti proovida ainult siis, kui side ebaõnnestub. Isegi SOAP-i vaheühendite kasutamisel pakub SOAP tänu oma sisseehitatud eduka/uuesti proovimise loogikale täielikku töökindlust.
- SOAP vastab juba ACID standarditele. Määrates, kuidas tehingud saavad andmebaasiga suhelda, vähendab ACID-i vastavus kõrvalekaldeid ja kaitseb andmebaasi järjepidevust. Kuna ACID on teistest andmete järjepidevuse mudelitest ettevaatlikum, kasutatakse seda sageli tundlike finants- või muude tehingute haldamisel.
- Programmeerijatel on sellest lihtne aru saada, kuna SOAP on täielikult XML-põhine suhtlus.
- XML-sõnumsideprotokoll on HTTP-protokolli täiendus.
- Teavet ühest arvutist teise saab levitada SOAP-sõnumite kaudu.
- Rakendada saab ka klient-serveri arhitektuuri. SOAP-protokolli sõnumit saab klient kasutada serveripoolsele kaugprotseduurikõnele helistamiseks.
REST Vs SOAP Erinevused
1. arhitektuur
API on mõeldud peamiselt serveris oleva rakenduse äriloogika konkreetsete komponentide kuvamiseks. Kui REST kasutab samal eesmärgil URI-sid, siis SOAP kasutab selleks teenuseliidest.
REST API-d luuakse pärast andmeid, SOAP API-d aga pärast API illustreeritud funktsioone. Võrreldes SOAP-iga, mis on rohkem funktsioonipõhine, on REST rohkem andmepõhise disainiga.
2. Vahemällu salvestamine
Vahemällu salvestatavateks märgitud andmeid saavad brauserid uuesti kasutada, ilma et nad peaksid serverile uut päringut esitama. Aja ja vaeva kokkuhoid on selle eeliseks.
Vastuseid ei salvestata HTTP-tasemel vahemällu, kuna SOAP-päringud esitatakse POST-päringute kaudu, mida HTTP-standard peab mitte-idempotentseks. Kui soovite kasutada vahemällu, peate siiski looma vajalikud tehnikad, kuna REST API-d seda teostust ei sisalda.
3. Ressursid ja ribalaius
SOAP-i kasutatava ümbriku stiilis kasuliku koormuse ülekande tõttu on üldkulud mõõdukalt suurenenud, mis nõuab täiendavat ribalaiust. RESTi kerge olemus on sellistes olukordades kasuks, kuna seda kasutatakse üldiselt veebiteenuste jaoks.
4. Turvalisus
Soovitav on WS-turvalisus, mida SOAP toetab ja mis on transporditasandil veidi põhjalikum kui SSL. Samuti sobib suurepäraselt ettevõtte tasemel turvameetmete kaasamine sellega.
SSL-i abil täielikku krüptimist toetavad nii SOAP kui ka REST ning REST saab kasutada HTTPS-i, HTTP-protokolli turvalist varianti.
5. Kasulike koormate käsitlemine
Interneti kaudu edastatavaid andmeid nimetatakse kasulikuks koormuseks. Kasulik koormus, mida peetakse „raskeks”, vajab lisaressursse. Võrreldes SOAP-iga, mis kasutab XML-i, kasutab REST kasuliku koormuse vähendamiseks sageli JSON-i ja HTTP-d.
Tavaliselt peab klient SOAP API-dele juurdepääsuks kasutama spetsiaalset klienditeeki koos genereeritud koodiga nende äärmiselt range suhtluslepingu tõttu.
Selle tulemusena pakub SOAP madalamat abstraktsioonitaset kui REST ja on serveriga tihedamalt seotud.
Millal kasutada RESTi?
- Avalike API-de loomine: REST API-sid eelistatakse avalike veebiteenuste loomiseks, kuna neid peetakse lihtsamaks kasutada ja kasutusele võtta kui SOAP API-sid. Lisaks pakub SOAP mitmeid sisseehitatud turvameetmeid, mida REST-il ei ole, kuigi avatud andmete ja teenustega töötamisel pole neid omadusi vaja.
- Mobiilirakenduste loomine: REST sobib suurepäraselt mobiilirakenduste loomiseks, kuna see on väike, tõhus, olekuta ja vahemällu salvestatav.
- Kasutades nappe serveriressursse ja ribalaiust: kõik taotlused REST API-le peavad olema olekuta, mis tähendab, et iga interaktsioon on eraldi ning iga päring ja vastus sisaldab kõiki selle interaktsiooni lõpuleviimiseks vajalikke andmeid. Server ei salvesta eelmiste päringute kirjeid, kuna käsitleb neid iga uue päringuna. Selle tulemusena vajab server palju vähem mälu ja töötab kiiremini, kuna päring ei nõua täiendavaid toiminguid ega ajalooliste andmete hankimist.
Millal SEEPI kasutada?
- Privaatsete API-de loomine, eriti suurettevõtete jaoks: SOAP sobib suurepäraselt ettevõtete rakenduste jaoks, kuna see võimaldab andmevoogu detsentraliseeritud hajutatud keskkonnas ja sisaldab mitmeid võrguturbefunktsioone.
- Kasutades aluskihina muud transpordiprotokolli peale HTTP: SOAP ei sõltu HTTP-st kui aluskihist. Olenevalt teie rakendusest võite kasutada SMTP-d (lihtne meiliedastusprotokoll), JMS-i (Java Messaging Service) või muud transpordiprotokolli.
- Olekupõhiste operatsioonidega töötamine: Erinevalt REST API-de päringutest on SOAP API-de päringud olekupõhised, mis tähendab, et server salvestab teabe kliendi kohta ja kasutab seda päringute või toimingute ahelas. Isegi kui see kasutab rohkem serveri ribalaiust ja ressursse, on see tavapäraste või seotud toimingute (nt pangaülekannete) tegemiseks ülioluline.
Järeldus
REST-i ja SOAP-i API-de võrdlus muudab üsna selgeks, et REST on SOAP-ile eelistatum. Siiski on olukordi, kus SOAP API on vajalik. Teatud juhtudel luuakse veebiteenused REST-i ja SOAP-i API-de kombineerimise teel.
Seetõttu määrab kasutusjuhtum, milline API stiil töötab kõige paremini.
Jäta vastus