Uz mākoni balstīti API datu modeļi ir ne tikai uzlabojuši mākoņa pieredzi, bet arī nodrošinājuši iespēju izstrādātājiem un administratoriem integrēt darba slodzes mākonī, izmantojot šīs API. Lielākajai daļai uzņēmumu API ļauj koplietot informāciju dažādās lokālās un mākoņdatošanas lietojumprogrammās. Viņiem ir arī svarīga loma, lai vienmērīgāk integrētu platformas darba slodzes. Tā kā mākoņu ieviešana turpina pieaugt, ir lielāks pieprasījums pēc integrācijas punktiem starp lietojumprogrammām mākoņa vidē un ārpus tās. Daudzmākoņu stratēģijas pieaugums kopā ar nepieciešamību uzlabot pārrobežu mākoņu iespējas ir palielinājis atkarību no mākoņa API vides. Bet kura pieeja ir labāka un kādu atbalstu jūs saņemat savā mākoņa vidē?
ZIEPES īsumā
SOAP (saīsinājums no vienkāršā objekta piekļuves protokola), kas ir vecāka pieeja, visā nozarē nodrošināja atbalstu, sākot no tādiem produktu uzņēmumiem kā IBM un Microsoft līdz pakalpojumu ieviesējiem. Tam bija arī visaptverošs, tomēr sarežģīts standartu kopums. Microsoft komanda, kas izstrādāja SOAP, padarīja to ļoti elastīgu - lai varētu sazināties privātajos tīklos, internetā un e-pastos. To atbalstīja arī vairāki standarti. Sākotnējā SOAP versija bija daļa no specifikācijas, kas saturēja arī universālo aprakstu, atklāšanas un integrācijas (UDDI) un tīmekļa pakalpojumu apraksta valodu (WSDL).
SOAP būtībā nodrošina aploksni tīmekļa pakalpojumu ziņojumu sūtīšanai. Pati arhitektūra ir paredzēta, lai palīdzētu veikt dažādas darbības starp programmatūras programmām. Saziņa starp programmām parasti notiek, izmantojot uz XML balstītus pieprasījumus un HTTP balstītas atbildes. HTTP galvenokārt tiek izmantots sakaru protokols, taču var tikt izmantoti arī citi protokoli.
SOAP ziņojumā ir dažas obligātās daļas, piemēram, APVIENOTI, GALVA, ĶERMENIS, un KĻŪDA. TheAPVIENOT objekts nosaka XML ziņojuma pieprasījuma sākumu un beigas, GALVA satur visus galvenes elementus, kurus jāapstrādā serverim, un ĶERMENIS satur atlikušo XML objektu, kas veido pieprasījumu. KĻŪDA objektam tiek izmantota jebkura kļūdu apstrāde.
ATPŪTA
REST (reprezentatīvā stāvokļa pārsūtīšana) parasti tiek saukts par arhitektūras stilu, nevis protokolu, ko izmanto tīmekļa pakalpojumu veidošanai. REST arhitektūra ļauj sazināties starp divām programmatūras programmām, kur viena programma var pieprasīt un apstrādāt resursus no otras. REST pieprasījums piekļūt resursiem mērķprogrammā izmanto HTTP darbības vārdus: GŪT, POST, PUT, un DZĒST. Šajos pieprasījumos var izmantot datu formātu, tostarp XML, HTML un JSON. JSON ir visvairāk vēlamais, jo tas ir vispiemērotākais un viegli lietojams. lielākā daļa REST API ir balstītas uz URI (Uniform Resource Identifier) un ir specifiskas HTTP protokolam.
REST ir izstrādātājiem draudzīgs, jo tā vienkāršākais stils atvieglo ieviešanu un lietošanu nekā SOAP. REST ir mazāk izteiksmīgs, un, sazinoties starp diviem galapunktiem, tiek nosūtīts mazāks datu apjoms.
Kāpēc ziepes vai atpūta?
Kaut arī SOAP ir tāds pats kā aploksnes izmantošana, kuras iekšpusē ir daudz apstrādes informācijas, REST var uzskatīt par pastkarti, kurai kā galamērķa adrese ir URI, tā ir viegla un to var saglabāt kešatmiņā. REST ir balstīts uz datiem, un to galvenokārt izmanto, lai piekļūtu resursiem (URI) noteiktiem datiem; SOAP ir protokols, kas ir balstīts uz funkcijām. REST nodrošina elastību, izvēloties datu formātu (vienkāršs teksts, HTML, XML vai JSON), savukārt SOAP izmanto tikai XML.
SOAP ir labi piemērots lietojumprogrammām, kurās jums nepieciešams augstāks drošības līmenis. SOAP nāk ar uzņēmuma līmeņa drošības funkcijām, kuras atbalsta WS-Security, kā arī SSL atbalstu. Ja vēlaties izstrādāt mobilās bankas risinājumu, SOAP API, iespējams, būtu pirmais drošības prasību apsvērums. SOAP nodrošina arī mēģinājumu loģiku garantētiem panākumiem un uzticamai komunikācijai. REST izmanto HTTP un var novērst sakaru kļūmes, tikai mēģinot atkārtoti, tomēr atkārtojuma mēģinājumu loģika nav iebūvēta ar REST. SOAP nodrošina iebūvētu atkārtotu loģiku.
Kas mainās mākoņa vietējā vidē?
No izstrādātāja viedokļa nekas īsti nemainās, izvēloties starp REST vai SOAP, taču, izstrādājot savu pakalpojumu mākoņdatošanas vidē, platformas perspektīva tiek apsvērta. Pakalpojumu pieejamībai un reakcijas laikam ir izšķiroša loma uzņēmuma pakalpojumu un vietējo mākoņa lietojumprogrammu projektēšanā. No drošības viedokļa WS-Security (Web Service Security) protokols, kas nodrošina gala līdz galam ziņojumu līmeņa drošību, izmantojot SOAP ziņojumus, tiek plaši izmantots mākoņdatošanā, lai aizsargātu vairuma ar mākoņdatošanu saistīto tīmekļa pakalpojumu drošību. Bet, lai pārvadātu ar drošību saistītu informāciju, WS-Security izmanto SAOP galvenes elementus. SOAP ziņojums ir XML tipa formātā, un tā lielums parasti ir daudz lielāks nekā faktiskais ziņojums binārā formātā. Tas palielina laiku un apstrādi, lai sazinātos un apstrādātu datus. Tas var būt diskusiju arguments, izvēloties REST salīdzinājumā ar SOAP, taču notiek pāreja no SOAP uz REST neatkarīgi no platformas, kurā jūsu lietojumprogramma darbosies.
2016. gada beigās Microsoft Azure pievienoja SOAP caurlaides atbalstu Azure API pārvaldībai, kas palīdz izstrādātājiem izveidot starpniekserveri savām SOAP API tāpat kā viņi izveido starpniekserveri REST / HTTP API. Izmantojot SOAP caurlaides atbalstu, varat importēt WSDL dokumentus un izveidot jaunu API starpniekserveri; process izskata visas dokumenta SOAP darbības un efektīvi izveido tās API galapunktos. Nākamajā versijā mēs varam redzēt funkciju, kas pieprasīta, lai izveidotu REST priekšgalu, izmantojot SOAP aizmuguri.
AWS pasaulē lielākā daļa AWS API ir pieejama tikai caur REST, un tām ir ierobežots SOAP atbalsts. EC2 resursi ir pieejami, izmantojot REST vai Query API, savukārt SOAP API EC2 ir novecojusi kopš 2015. gada beigām. Pakalpojumi, piemēram, Amazon S3 un RDS, atbalsta arī REST, savukārt SOAP tiek atbalstīti tikai caur HTTPS; HTTP ziepes ir novecojušas. Amazon SQS vairs neatbalsta SOAP. Lai gan šķiet, ka REST vada AWS API, Amazon API vārteja integrējas AWS ekosistēmā un sniedz atbalstu RESTful API izveidošanai, pārvaldībai un izvietošanai, lai atklātu HTTP / HTTPS galapunktus, AWS Lambda funkcijas un / vai citus AWS pakalpojumus. API vārteja palīdz arī pakļauto API metožu izsaukšanai, izmantojot priekšgala HTTP galapunktus.
Arvien vairāk atbalsta tiek virzīts uz RESTful API. Tā vienkāršība ar darbības vārdiem līdzīgām darbībām padara to draudzīgu izstrādātājiem. Tas ir saderīgs ar lielāko daļu formātu un ir ērti lietojams. Arī SOAP nav saulrieta, taču REST noteikti būs populāra izstrādātāju kopienas vidū.
