Vai vēlaties saistīt savu lietotni ar Facebook, lai tā varētu automātiski ģenerēt ziņas, vai ar Instagram, lai varētu atkārtoti publicēt fotoattēlus ar noteiktiem atsauces tagiem?
Varat arī vēlēties savā vietnē iekļaut YouTube videoklipus. Lietojumprogrammu saskarnes ļauj veikt visus šos un citus uzdevumus (API).
Pateicoties API, piemēram, Instagram API, Facebook API un YouTube API, dažādas lietojumprogrammas var “sarunāties” viena ar otru drošā un standartizētā veidā.
Citiem vārdiem sakot, programma var ņemt līdzekļus vai datus no citas programmatūras un izmantot tos, lai uzlabotu savas funkcijas vai lietotāja pieredzi. Bet kā lietotnes var iesniegt šos pieprasījumus, apstrādāt tos un atbildēt uz tiem citiem saprotamā veidā?
Tas ir atkarīgs no tā, kā API tika izveidota. Apspriežot API (lietojumprogrammu programmēšanas saskarnes) dizainu, parasti tiek salīdzinātas SOAP un REST, divas no visievērojamākajām API paradigmām.
Tiklīdz SOAP API (Simple Object Access Protocol) kļuva par zelta standartu tādām firmām kā Oracle, Sun un PayPal, aptuveni gadu vēlāk bija līdzvērtīga un pretēja reakcija uz REST API no Google, Amazon un eBay.
Šajā ziņojumā mēs salīdzināsim un pretstatīsim SOAP API ar REST API, lai jūs varētu izlemt, kura ir vislabākā jūsu vajadzībām.
Mēs sāksim ar API definēšanu.
Kas ir API?
Lietojumprogrammu saskarne tiek saukta par API. API būtībā ir metožu un funkciju kopums, kas ļauj izstrādāt lietotnes. Viņi iegūst piekļuvi dažādu programmu, pakalpojumu vai operētājsistēmu informācijai un funkcijām.
Tie kalpo kā sava veida starpnieks starp dažādām programmatūras sistēmām. Tie ļauj "runāt" starp divām nesaistītām programmām.
Ņemsim par piemēru biržas brokeri, kurš aktīvi iesaistās tirdzniecībā un finanšu tirgos. Automatizētu kolekcija tirdzniecības algoritmi var savienot ar tirgotāja iecienītāko tirdzniecības brokeru platformu, izmantojot API. Tas ļauj jums, tirgotājam, veikt elektroniskus darījumus vai redzēt reāllaika kotācijas un cenu datus.
Kas ir ATPŪTA?
Īstās “tīmekļa pakalpojumu” API ietver REST (pārstāvības stāvokļa pārsūtīšanu). REST API ir veidotas uz URI (vienotiem resursu identifikatoriem, no kuriem URL ir īpašs veids), HTTP protokolu un neticami pārlūkprogrammu saderīgu JSON datu formātu.
SOAP protokolu, kā mēs jau minējām, iespējams, arī varētu izmantot. REST API var būt viegli izveidot un attīstīt, taču tās var būt arī milzīgas un sarežģītas — viss ir atkarīgs no tā, kā tās ir izveidotas, paplašinātas un paredzētas.
Resursu ierobežojumi, samazinātas drošības prasības, pārlūkprogrammas klientu saderība, atklājamība, datu stāvoklis un mērogojamība ir daži iemesli, kādēļ jūs vēlaties izstrādāt API, lai tā būtu RESTful — lietas, kas faktiski attiecas uz tīmekļa pakalpojumiem.
REST piedāvā vieglāku iespēju. SOAP bija grūti lietojams un apgrūtinošs daudziem izstrādātājiem. Piemēram, izmantojot SOAP ar JavaScript, ir jāieraksta daudz koda, lai veiktu vienkāršas darbības, jo katru reizi ir jāizveido nepieciešamā XML struktūra.
REST (parasti) XML pieprasījuma vietā izmanto vienkāršu URL. Lai gan retos gadījumos jums ir jāpiedāvā sīkāka informācija, lielākā daļa RESTful tīmekļa pakalpojumu izmanto tikai URL tehniku.
REST var izmantot četrus HTTP 1.1 darbības vārdus GET, POST, PUT un DELETE, lai veiktu darbības. Atšķirībā no SOAP, REST nav nepieciešams, lai atbilde būtu XML formātā.
Ir pieejami uz REST balstīti tīmekļa pakalpojumi, kas izvada datus ar komandu atdalītās vērtības (CSV), JavaScript objektu notācijas (JSON) un patiešām vienkāršās sindikācijas (RSS) formātā (RSS).
Mērķis ir, lai jūs varētu iegūt vajadzīgos rezultātus viegli parsējamā formātā valodā, kuru izmantojat savai lietojumprogrammai.
Apkalpošana
- REST galvenokārt uzsver vienkāršību, pateicoties HTTP protokoliem.
- Tīmeklis ir vislabāk piemērots ATPŪTAI. Tas ir saderīgs ar pārlūkprogrammām, jo JSON tiek izmantots kā datu formāts.
- REST ir slavens ar izcilu mērogojamību un ātrumu.
- Klienta-servera savienojumus un arhitektūras padara pieejamākas, izmantojot REST API. Ja tas ir RESTful, tas tiek konstruēts, izmantojot šo klienta-servera modeli, ar abām pusēm, kas nodod datu lietderīgās slodzes, turp un atpakaļ.
- REST API izmanto atsevišķu standarta saskarni. Nodrošinot visu lietotņu vienotu savienojumu un vienu un to pašu vārteju, tiek racionalizēta lietojumprogrammu saziņa ar API.
Kas ir SOAP?
Tā paša protokols, ko sauc par SOAP (Simple Object Access Protocol), ir nedaudz sarežģītāks nekā REST, jo tas nosaka vairāk standartu, tostarp tos, kas saistīti ar drošību un ziņojumu piegādi.
Šīs raksturīgās normas ir saistītas ar nedaudz papildu pieskaitāmajām izmaksām. Tomēr tie var būt izšķirošs faktors uzņēmumiem, kuriem nepieciešama plašāka drošības, darījumu un ACID (atomiskums, konsekvence, izolācija, izturība) atbilstības iespējas.
Šī salīdzinājuma labad ir svarīgi atzīmēt, ka daudzas no SOAP priekšrocībām bieži neattiecas uz tīmekļa pakalpojumu lietojumprogrammām, padarot tās piemērotākas uzņēmuma tipa scenārijiem.
Augstākas drošības pakāpes (piemēram, ja a Mobilā lietotne mijiedarbojas ar banku), ziņojumapmaiņas lietotnes, kurām nepieciešama uzticama saziņa, mijiedarbība ar mantotajām sistēmām vai atbilstība ACID ir daži iemesli, kāpēc vēlaties izveidot lietojumprogrammu, izmantojot SOAP API.
SOAP piedāvātās ziņojumapmaiņas iespējas ir pilnībā balstītas uz XML. Vecākas ar internetu nesaderīgas tehnoloģijas, piemēram, Distributed Component Object Model (DCOM) un Common Object Request Broker Architecture, tika aizstātas ar SOAP, kad to pirmo reizi izveidoja Microsoft (CORBA).
Paļaušanās uz binārajiem sakariem izraisa šo sistēmu atteici. Internetā XML ziņojumapmaiņa, piemēram, SOAP, darbojas labāk.
Apkalpošana
- SOAP drošība ir ievērojami stingrāka. WS-Security ir iebūvēts standarts, kas papildus SSL atbalstam piedāvā SOAP papildu uzņēmuma līmeņa drošības iespējas, ja nepieciešams.
- Veiksmīga/atkārtota argumentācija uzticamai ziņojumapmaiņas veiktspējai. Tā kā REST trūkst standartizēta ziņojumu mehānisma, tas var mēģināt atkārtoti tikai tad, ja komunikācija neizdodas. Pat tad, ja tiek izmantoti SOAP starpprodukti, SOAP piedāvā pilnīgu uzticamību, pateicoties iebūvētajai veiksmīgo/atkārtota mēģinājuma loģikai.
- SOAP jau atbilst ACID standartiem. Nosakot, kā darījumi var mijiedarboties ar datu bāzi, ACID atbilstība samazina anomālijas un nodrošina datu bāzes konsekvenci. Tā kā ACID ir piesardzīgāks nekā citi datu konsekvences modeļi, to bieži izmanto, pārvaldot sensitīvus darījumus neatkarīgi no tā, vai tie ir finanšu vai citi.
- Programmētājiem to ir viegli saprast, jo SOAP ir pilnībā uz XML balstīta saziņa.
- XML ziņojumapmaiņas protokols ir HTTP protokola papildinājums.
- Saziņu no viena datora uz otru var izplatīt, izmantojot SOAP ziņojumapmaiņu.
- Var ieviest arī klienta-servera arhitektūru. Klients var izmantot SOAP protokola ziņojumu, lai izsauktu attālās procedūras zvanu, kas atrodas servera pusē.
REST Vs SOAP atšķirības
1. arhitektūra
API ir paredzēts, lai galvenokārt parādītu konkrētas lietojumprogrammas biznesa loģikas sastāvdaļas serverī. Kamēr REST izmanto URI tam pašam mērķim, SOAP šim nolūkam izmanto pakalpojuma saskarni.
REST API tiek izveidotas pēc datiem, savukārt SOAP API tiek izstrādātas pēc API ilustrētajām funkcionalitātēm. Salīdzinot ar SOAP, kas ir vairāk balstīta uz funkcijām, REST ir vairāk uz datiem orientēts dizains.
2. Caching
Datus, kas ir atzīmēti kā kešatmiņā saglabājami, pārlūkprogrammas var atkal izmantot, neprasot serverim veikt jaunu pieprasījumu. Ietaupot laiku un pūles, tas ir ieguvums.
Atbildes netiks saglabātas kešatmiņā HTTP līmenī, jo SOAP vaicājumi tiek iesniegti, izmantojot POST pieprasījumus, kurus HTTP standarts uzskata par neefektīviem. Ja vēlaties izmantot kešatmiņu, jums joprojām ir jāizveido nepieciešamie paņēmieni, jo REST API neietver šo ieviešanu.
3. Resursi un joslas platums
SOAP izmantotās aploksnes veida lietderīgās slodzes pārsūtīšanas dēļ ir neliels pieskaitāmo izmaksu pieaugums, kas rada nepieciešamību pēc papildu joslas platuma. REST vieglais raksturs šajās situācijās ir ieguvums, jo to parasti izmanto tīmekļa pakalpojumiem.
4. drošība
Vēlama ir WS drošība, ko atbalsta SOAP un kas transporta līmenī ir nedaudz rūpīgāka par SSL. Arī uzņēmuma līmeņa drošības pasākumu iekļaušana tajā ir lieliski piemērota.
Pilnu šifrēšanu, izmantojot SSL, atbalsta gan SOAP, gan REST, un REST var izmantot HTTPS — HTTP protokola drošo variantu.
5. Kravu apstrāde
Dati, kas pārsūtīti caur internetu, tiek saukti par lietderīgo slodzi. Kravai, kas tiek uzskatīta par "smagu", ir nepieciešami papildu resursi. Salīdzinot ar SOAP, kas izmanto XML, REST bieži izmanto JSON un HTTP, lai palīdzētu samazināt lietderīgo slodzi.
Lai piekļūtu SOAP API, Klientam parasti ir jāizmanto specializēta klienta bibliotēka ar ģenerētu kodu, jo tas ir ļoti stingrs saziņas līgums.
Rezultātā SOAP piedāvā mazāku abstrakcijas līmeni nekā REST un ir ciešāk saistīts ar serveri.
Kad lietot REST?
- Publisku API izveide: Publisku tīmekļa pakalpojumu izveidei priekšroka tiek dota REST API, jo tiek uzskatīts, ka tās ir vienkāršāk lietojamas un pārņemamas nekā SOAP API. Turklāt SOAP piedāvā vairākus iebūvētus drošības pasākumus, kuru REST nav, lai gan šie raksturlielumi nav nepieciešami, strādājot ar atvērtiem datiem un pakalpojumiem.
- Mobilo lietotņu izveide: REST ir lieliski piemērots mobilo lietojumprogrammu izveidei, jo tas ir mazs, efektīvs, bezvalsts un saglabājams kešatmiņā.
- Izmantojot ierobežotos servera resursus un joslas platumu: visiem pieprasījumiem REST API ir jābūt bezvalstniekiem, kas nozīmē, ka katra mijiedarbība ir atsevišķa un katrs pieprasījums un atbilde satur visus datus, kas nepieciešami šīs mijiedarbības pabeigšanai. Serveris nesaglabā iepriekšējo pieprasījumu ierakstus, jo tas katru no tiem uzskata par jaunu pieprasījumu. Tā rezultātā serverim ir nepieciešams daudz mazāk atmiņas un tas darbojas ātrāk, jo pieprasījumam nav nepieciešama turpmāka darbība vai vēsturisko datu izguve.
Kad lietot SOAP?
- Privātu API izveide, īpaši lieliem uzņēmumiem: SOAP ir lieliski piemērots korporatīvajām lietojumprogrammām, jo nodrošina datu plūsmu decentralizētā, izplatītā vidē un satur vairākus tiešsaistes drošības līdzekļus.
- Kā pamatā esošā slāņa izmantošana transporta protokolu, kas nav HTTP: SOAP nav atkarīgs no HTTP kā pamatā esošā slāņa. Atkarībā no lietojumprogrammas varat izmantot SMTP (Vienkāršo pasta pārsūtīšanas protokolu), JMS (Java ziņojumapmaiņas pakalpojumu) vai citu transporta protokolu.
- Darbs ar statusful operācijām: Atšķirībā no pieprasījumiem REST API, pieprasījumi SOAP API ir statusa dati, kas nozīmē, ka serveris saglabā informāciju par klientu un izmanto to pieprasījumu vai darbību ķēdē. Pat ja tas patērē vairāk servera joslas platuma un resursu, tas ir ļoti svarīgi, lai veiktu parastās vai saistītās darbības, piemēram, bankas pārskaitījumus.
Secinājumi
Salīdzinot REST un SOAP API, ir skaidrs, ka REST ir labāka par SOAP. Tomēr ir situācijas, kad ir nepieciešama SOAP API. Dažos gadījumos tīmekļa pakalpojumi tiek izveidoti, apvienojot REST un SOAP API.
Tāpēc lietošanas gadījums noteiks, kurš API stils darbosies vislabāk.
Atstāj atbildi