Ali želite svojo aplikacijo povezati s Facebookom, da lahko samodejno ustvarja objave, ali z Instagramom, da lahko ponovno objavite fotografije z določenimi hashtagi?
Na svoje spletno mesto lahko vključite tudi videoposnetke YouTube. Vmesniki za programiranje aplikacij vam omogočajo izvajanje vseh teh nalog in več (API).
Različne aplikacije lahko med seboj »govorijo« na varen in standardiziran način zahvaljujoč API-jem, kot so Instagram API, Facebook API in YouTube API.
Z drugimi besedami, program lahko vzame funkcije ali podatke iz drugega dela programske opreme in jih uporabi za izboljšanje lastnih funkcij ali uporabniške izkušnje. Toda kako lahko aplikacije postavijo te zahteve, jih obdelajo in se nanje odzovejo na način, ki ga drugi razumejo?
To je odvisno od tega, kako je bil API ustvarjen. Ko razpravljamo o zasnovah API (aplikacijskega programskega vmesnika), je običajno primerjati SOAP in REST, dve najvidnejši paradigmi API.
Takoj, ko so API-ji SOAP (Simple Object Access Protocol) postali zlati standard za podjetja, kot so Oracle, Sun in PayPal, je približno leto kasneje prišlo do enakega in nasprotnega odziva na API-je REST iz Googla, Amazona in eBaya.
V tej objavi bomo primerjali in primerjali API-je SOAP z API-ji REST, da se boste lahko odločili, kateri je najboljši za vaše namene.
Začeli bomo z definiranjem API-ja.
Kaj je API?
Programski vmesnik aplikacij se imenuje API. API-ji so v bistvu zbirka metod in funkcij, ki omogočajo razvoj aplikacij. Dobijo dostop do informacij in funkcij različnih programov, storitev ali operacijskih sistemov.
Služijo kot nekakšni posredniki med različnimi programskimi sistemi. Omogočajo »pogovarjanje« med dvema nepovezanima programoma.
Vzemimo primer borznega posrednika, ki se aktivno ukvarja s trgovanjem in finančnimi trgi. Zbirka avtomatiziranih algoritmi trgovanja se lahko prek API-ja poveže s trgovčevo priljubljeno platformo trgovalnega posrednika. To vam kot trgovcu omogoča izvajanje elektronskih transakcij ali ogled ponudb in podatkov o cenah v realnem času.
Kaj je REST?
API-ji za prave »spletne storitve« vključujejo REST (Representational State Transfer). API-ji REST so zgrajeni na URI-jih (Uniform Resource Identifier, od katerih je URL posebna vrsta), protokolu HTTP in formatu podatkov JSON, ki je izjemno združljiv z brskalnikom.
Protokol SOAP, kot smo že omenili, bi lahko bil tudi uporabljen. API-je REST je lahko enostavno ustvariti in razširiti, lahko pa so tudi ogromni in težki – vse je odvisno od tega, kako so ustvarjeni, razširjeni in čemu so namenjeni.
Omejitve virov, zmanjšane varnostne zahteve, združljivost odjemalca brskalnika, odkrivanje, zdravje podatkov in razširljivost so nekateri razlogi, zakaj bi želeli razviti API, ki bi bil RESTful – stvari, ki dejansko veljajo za spletne storitve.
REST ponuja lažjo možnost. SOAP je bil težak za uporabo in obremenjujoč za mnoge razvijalce. Na primer, uporaba SOAP z JavaScriptom zahteva pisanje veliko kode za dokončanje preprostih operacij, saj je treba vsakokrat ustvariti potrebno strukturo XML.
REST (običajno) uporablja neposreden URL namesto zahteve XML. Čeprav obstajajo redke okoliščine, ko morate ponuditi več podrobnosti, večina spletnih storitev RESTful uporablja samo tehniko URL.
Štiri glagole HTTP 1.1 GET, POST, PUT in DELETE lahko REST uporablja za izvajanje operacij. Za razliko od SOAP, REST ne potrebuje, da je odgovor v XML.
Na voljo so spletne storitve, ki temeljijo na REST in izpisujejo podatke v formatih Command Separated Value (CSV), JavaScript Object Notation (JSON) in Really Simple Syndication (RSS) (RSS).
Cilj je, da lahko dobite rezultate, ki jih potrebujete, v obliki, ki jo je enostavno razčleniti, v jeziku, ki ga uporabljate za svojo aplikacijo.
Lastnosti
- REST zaradi protokolov HTTP poudarja predvsem preprostost.
- Splet je najbolj primeren za REST. Združljiv je z brskalniki, ker se kot format podatkov uporablja JSON.
- REST je znan po izjemni razširljivosti in hitrosti.
- Povezave med odjemalcem in strežnikom ter arhitekture so zaradi API-jev REST bolj dostopne. Če je RESTful, je zgrajen z uporabo tega modela odjemalec-strežnik, s povratnimi potovanji med obema stranema, ki prenašata koristne podatke.
- API-ji REST uporabljajo samoten standardni vmesnik. Zagotavljanje enotne povezave vseh aplikacij prek istega prehoda poenostavlja komunikacijo aplikacij z API-jem.
Kaj je SOAP?
Njegov lastni protokol, imenovan SOAP (Simple Object Access Protocol), je nekoliko bolj zapleten kot REST, saj določa več standardov, vključno s tistimi, povezanimi z varnostjo in dostavo sporočil.
Te inherentne norme prinašajo nekaj dodatnih stroškov. Vendar pa so lahko odločilni dejavnik za podjetja, ki potrebujejo obsežnejšo varnost, transakcije in zmogljivosti skladnosti z ACID (Atomicity, Consistency, Isolation, Durability).
Zaradi te primerjave je pomembno opozoriti, da se mnoge prednosti SOAP pogosto ne nanašajo na aplikacije spletnih storitev, zaradi česar so bolj primerne za poslovne scenarije.
Višje stopnje varnosti (na primer, ko a aplikacija za mobilne naprave komunicira z banko), aplikacije za sporočanje, ki zahtevajo zanesljivo komunikacijo, interakcijo s podedovanimi sistemi ali skladnost z ACID je nekaj razlogov, zakaj bi želeli oblikovati aplikacijo, ki uporablja API SOAP.
Zmožnosti sporočanja, ki jih ponuja SOAP, v celoti temeljijo na XML. Starejše tehnologije, ki niso združljive z internetom, kot sta Distributed Component Object Model (DCOM) in Common Object Request Broker Architecture, je nadomestil SOAP, ko ga je prvič ustvaril Microsoft (CORBA).
Zanašanje na binarne komunikacije povzroči, da ti sistemi ne uspejo. V internetu sporočanje XML, kot je tisto, ki ga uporablja SOAP, deluje bolje.
Lastnosti
- Varnost SOAP je bistveno strožja. WS-Security je vgrajen standard, ki po potrebi poleg podpore SSL ponuja dodatne varnostne zmogljivosti SOAP na ravni podjetja.
- Utemeljitev uspešnega/ponovnega poskusa za zanesljivo delovanje sporočanja. Ker REST nima standardiziranega mehanizma za sporočila, lahko poskusi znova šele, ko komunikacija ne uspe. Tudi pri uporabi vmesnih elementov SOAP ponuja SOAP zanesljivost od konca do konca zaradi svoje vgrajene logike uspešnega/ponovnega poskusa.
- SOAP je že v skladu s standardi ACID. Z narekovanjem, kako lahko transakcije medsebojno delujejo z bazo podatkov, skladnost s predpisi ACID minimizira anomalije in varuje konsistentnost baze podatkov. Ker je ACID bolj previden kot drugi modeli skladnosti podatkov, se pogosto uporablja pri upravljanju občutljivih transakcij, bodisi finančnih ali drugih.
- Programerjem je preprosto razumljivo, saj je SOAP komunikacija, ki v celoti temelji na XML.
- Protokol za sporočanje XML je dodatek k protokolu HTTP.
- Komunikacije iz enega računalnika v druge računalnike se lahko razširjajo prek sporočil SOAP.
- Lahko se implementira tudi arhitektura odjemalec-strežnik. Sporočilo protokola SOAP lahko odjemalec uporabi za klic oddaljenega klica procedure, ki se nahaja na strani strežnika.
Razlike med REST in SOAP
1. arhitektura
API je namenjen predvsem prikazu določenih komponent poslovne logike aplikacije na strežniku. Medtem ko REST uporablja URI-je za isti namen, SOAP za to uporablja storitveni vmesnik.
API-ji REST so ustvarjeni po podatkih, medtem ko so API-ji SOAP razviti po funkcionalnostih, ki jih API ponazarja. V primerjavi s SOAP, ki je bolj funkcionalno usmerjen, je REST bolj podatkovno usmerjen dizajn.
2. Predpomnjenje
Podatke, ki so bili označeni kot predpomnjeni, lahko brskalniki znova uporabijo, ne da bi morali poslati novo zahtevo strežniku. Prednost tega je prihranek časa in truda.
Odgovori ne bodo shranjeni v predpomnilniku na ravni HTTP, ker so poizvedbe SOAP poslane prek zahtev POST, ki jih standard HTTP šteje za neidempotentne. Če želite uporabiti predpomnjenje, morate še vedno zgraditi potrebne tehnike, saj API-ji REST ne vključujejo te izvedbe.
3. Viri in pasovna širina
Zaradi prenosa koristnega tovora v obliki ovojnice, ki ga uporablja SOAP, pride do skromnega povečanja režijskih stroškov, kar zahteva dodatno pasovno širino. Lahka narava REST je v teh situacijah prednost, ker se na splošno uporablja za spletne storitve.
4. Varnost
Zaželena je WS-varnost, ki jo SOAP podpira in je nekoliko bolj temeljita od SSL na transportni ravni. Vključevanje varnostnih ukrepov na ravni podjetja je prav tako popolno prileganje.
Šifriranje od konca do konca z uporabo SSL podpirata SOAP in REST, REST pa lahko uporablja HTTPS, varno različico protokola HTTP.
5. Ravnanje s tovorom
Podatki, ki se prenašajo prek interneta, se imenujejo koristni tovor. Koristni tovor, ki velja za "težkega", potrebuje dodatne vire. V primerjavi s SOAP, ki uporablja XML, REST pogosto uporablja JSON in HTTP za pomoč pri zmanjšanju obremenitve.
Za dostop do API-jev SOAP mora naročnik običajno uporabiti specializirano odjemalčevo knjižnico z ustvarjeno kodo zaradi njihove izjemno stroge komunikacijske pogodbe.
Posledično ponuja SOAP nižjo raven abstrakcije kot REST in je tesneje povezan s strežnikom.
Kdaj uporabiti REST?
- Ustvarjanje javnih API-jev: API-ji REST so prednostni za gradnjo javnih spletnih storitev, ker se zdijo enostavnejši za uporabo in sprejemanje kot API-ji SOAP. Poleg tega SOAP ponuja več vgrajenih varnostnih ukrepov, ki jih REST nima, čeprav te lastnosti niso potrebne pri delu z odprtimi podatki in storitvami.
- Izdelava mobilnih aplikacij: REST je popoln za gradnjo mobilnih aplikacij, saj je majhen, učinkovit, brez stanja in ga je mogoče predpomniti.
- Uporaba redkih strežniških virov in pasovne širine: Vse zahteve za API REST morajo biti brez stanja, kar pomeni, da je vsaka interakcija ločena in vsaka zahteva in odgovor vsebujeta vse podatke, potrebne za dokončanje te interakcije. Strežnik ne shranjuje zapisov prejšnjih zahtev, saj vsako obravnava kot novo zahtevo. Posledično strežnik potrebuje veliko manj pomnilnika in deluje hitreje, ker zahteva ne zahteva nadaljnjega ukrepanja ali pridobivanja zgodovinskih podatkov.
Kdaj uporabiti SOAP?
- Ustvarjanje zasebnih API-jev, zlasti za velika podjetja: SOAP je popoln za korporativne aplikacije, saj omogoča pretok podatkov v decentraliziranem, porazdeljenem okolju in vsebuje več spletnih varnostnih funkcij.
- Uporaba transportnega protokola, ki ni HTTP, kot osnovne plasti: SOAP ni odvisen od HTTP kot osnovnega sloja. Odvisno od vaše aplikacije lahko uporabite SMTP (Simple Mail Transfer Protocol), JMS (Java Messaging Service) ali drug transportni protokol.
- Delo z operacijami s stanjem: V nasprotju z zahtevami za API-je REST so zahteve za API-je SOAP s stanjem, kar pomeni, da strežnik shrani informacije o odjemalcu in jih uporabi v verigi zahtev ali operacij. Čeprav to uporablja več pasovne širine in virov strežnika, je ključnega pomena za izvajanje rutinskih ali povezanih dejanj, kot so bančna nakazila.
zaključek
Primerjava med API-ji REST in SOAP kaže povsem očitno, da je REST boljši od SOAP. Kljub temu obstajajo situacije, ko je potreben SOAP API. V nekaterih primerih so spletne storitve ustvarjene s kombinacijo API-jev REST in SOAP.
Zato bo primer uporabe določil, kateri slog API-ja bo deloval najbolje.
Pustite Odgovori