Debesimis pagrįsti API duomenų modeliai ne tik pagerino debesies patirtį, bet ir suteikė galimybę kūrėjams ir administratoriams integruoti darbo krūvius į debesį naudojant tas API. Daugumai įmonių API suteikia galimybę dalytis informacija įvairiose vietinėse ir debesų programose. Jie taip pat vaidina svarbų vaidmenį sklandžiau integruojant platformos darbo krūvius. Kadangi debesų pritaikymas ir toliau auga, reikia daugiau integracijos taškų tarp programų debesų aplinkoje ir už jos ribų. Daugelio debesų strategijos didėjimas ir poreikis tobulinti debesų galimybes padidino priklausomybę nuo debesies API aplinkos. Bet kuris požiūris yra geresnis ir kokią paramą gaunate debesų aplinkoje?
Muilas trumpai
Senesnis požiūris „SOAP“ (sutrumpintai nuo paprasto objekto prieigos protokolo) turėjo pramonės palaikymą, pradedant produktų kompanijomis, tokiomis kaip IBM ir „Microsoft“, ir baigiant paslaugų diegėjais. Taip pat buvo pateiktas išsamus, tačiau sudėtingas standartų rinkinys. „Microsoft“ komanda, sukūrusi SOAP, padarė tai labai lanksti - sugebėjo bendrauti privačiais tinklais, internetu ir el. Paštu. Tai palaikė ir keli standartai. Pradinė SOAP versija buvo dalis specifikacijos, kurioje taip pat buvo visuotinio aprašymo, paieškos ir integravimo (UDDI) ir žiniatinklio paslaugų aprašymo kalbos (WSDL).
SOAP iš esmės suteikia žiniatinklio paslaugų pranešimų siuntimo voką. Pati architektūra sukurta padėti atlikti įvairias operacijas tarp programinės įrangos. Bendravimas tarp programų paprastai vyksta per XML pagrįstas užklausas ir HTTP pagrįstus atsakymus. HTTP dažniausiai naudojamas ryšio protokolas, tačiau gali būti naudojami ir kiti protokolai.
SOAP pranešime yra keletas privalomų dalių, tokių kaip VOKAS, VADOVAS, KŪNASir KLAIDA.VOKAS objektas apibrėžia XML pranešimo užklausos pradžią ir pabaigą, VADOVAS yra visi antraštės elementai, kuriuos turi apdoroti serveris, ir KŪNAS yra likęs XML objektas, kuris sudaro užklausą. KLAIDA objektas naudojamas bet koks klaidų tvarkymas.
POILSIS
REST (Reprezentacinis valstybės perdavimas) paprastai vadinamas architektūros stiliumi, o ne protokolu, kuris naudojamas kuriant žiniatinklio paslaugas. REST architektūra leidžia bendrauti tarp dviejų programinės įrangos programų, kur viena programa gali reikalauti iš kitos išteklių ir jais naudotis. REST užklausa pasiekti resursus tikslinėje programoje naudoja HTTP veiksmažodžius: GAUTI, POST, ĮDĖKir IŠTRINTI. Šiose užklausose gali būti naudojamas duomenų formatas, įskaitant XML, HTML ir JSON. JSON yra labiausiai pageidaujamas, nes jis yra labiausiai suderinamas ir lengvai naudojamas. dauguma REST API yra pagrįstos URI (Uniform Resource Identifier) ir yra būdingos HTTP protokolui.
„REST“ yra patogi kūrėjams, nes dėl paprastesnio stiliaus jį lengviau įgyvendinti ir naudoti nei SOAP. REST yra mažiau išsami ir mažiau duomenų siunčiama bendraujant tarp dviejų galinių taškų.
Kodėl muilas ar poilsis?
Nors SOAP yra panašus į voką, kuriame yra daug apdorojimo informacijos, REST gali būti laikomas atviruku, kurio paskirties adresas yra URI, lengvas ir gali būti laikomas talpykloje. REST yra pagrįstas duomenimis ir pirmiausia naudojamas norint pasiekti tam tikrų duomenų šaltinį (URI); SOAP yra protokolas, valdomas pagal funkcijas. REST suteikia lankstumo renkantis duomenų formatą (paprastas tekstas, HTML, XML ar JSON), o SOAP naudoja tik XML.
SOAP puikiai tinka toms programoms, kur jums reikia aukštesnio lygio saugumo. SOAP turi įmonės lygio saugos funkcijas, palaikomas „WS-Security“, kartu su SSL palaikymu. Jei norite sukurti mobiliosios bankininkystės sprendimą, tikriausiai pirmiausia SOAP API turėtų būti atsižvelgiama į saugumo reikalavimus. SOAP taip pat pateikia pakartojimo logiką, užtikrinančią sėkmę ir patikimą ryšį. REST naudoja HTTP ir gali pašalinti ryšio gedimus tik bandydamas dar kartą, tačiau pakartojimo logika nėra integruota su REST. SOAP pateikia integruotą bandymo logiką.
Kas keičiasi debesyje esančioje aplinkoje?
Žiūrint iš kūrėjo perspektyvos, iš tikrųjų niekas nesikeičia renkantis tarp REST ar SOAP, tačiau kuriant savo paslaugą debesyje esančioje aplinkoje, į platformos perspektyvą atsižvelgiama. Paslaugų prieinamumas ir atsakymo laikas vaidina svarbų vaidmenį kuriant įmonės paslaugas ir „Cloud“ programas. Žiūrint iš saugumo, „WS-Security“ („Web Service Security“) protokolas, užtikrinantis visiško pranešimo lygio saugumą naudojant SOAP pranešimus, yra plačiai naudojamas debesų kompiuterijoje, siekiant apsaugoti daugumos su debesimis susijusių kompiuterių interneto paslaugų saugumą. Tačiau „WS-Security“ naudoja SAOP antraštės elementus su saugumu susijusiai informacijai perduoti. SOAP pranešimas yra XML tipo formato ir paprastai yra daug didesnis nei tikrasis pranešimas dvejetainiu formatu. Tai padidina laiką ir apdorojimą duomenims perduoti ir apdoroti. Tai gali būti diskusijų argumentas renkantis REST, palyginti su SOAP, tačiau pereinama nuo SOAP prie REST, nepaisant platformos, kurioje bus vykdoma jūsų programa.
2016 m. Pabaigoje „Microsoft Azure“ prie „Azure API Management“ pridėjo SOAP perėjimo palaikymą, kuris kūrėjams padeda sukurti savo SOAP API tarpinį serverį tokiu pačiu būdu, kaip ir REST / HTTP API tarpinį serverį. Naudodamiesi SOAP pralaidumo palaikymu, galite importuoti WSDL dokumentus ir sukurti naują API tarpinį serverį; procesas apžiūri visus dokumento SOAP veiksmus ir efektyviai sukuria juos į API galinius taškus. Būsimoje versijoje galime pamatyti funkciją, kurios prašoma sukurti „REST“ sąsają naudojant „SOAP“ vidinę dalį.
AWS pasaulyje dauguma AWS API yra prieinamos tik per REST ir turi ribotą SOAP palaikymą. EC2 šaltiniai yra prieinami per REST arba Query API, o ECAP SOAP API buvo nebenaudojama nuo 2015 m. Pabaigos. Tokios paslaugos kaip „Amazon S3“ ir „RDS“ taip pat palaiko „REST“, o SOAP palaiko tik per HTTPS; HTTP muilas nebenaudojamas. „Amazon SQS“ nebepalaiko SOAP. Nors atrodo, kad REST vadovauja AWS API, „Amazon API Gateway“ integruojasi į AWS ekosistemą ir teikia paramą kuriant, valdant ir diegiant „RESTful“ API, kad būtų atskleisti galiniai HTTP / HTTPS galiniai taškai, „AWS Lambda“ funkcijos ir (arba) kitos AWS paslaugos. API šliuzas taip pat padeda iškviesti eksponuojamus API metodus per front-end HTTP galinius taškus.
Vis daugiau ir daugiau palaikoma link RESTful API. Paprastumas su veiksmažodžiu panašiomis operacijomis daro jį draugišką kūrėjams. Jis suderinamas su daugeliu formatų ir yra lengvai naudojamas. SOAP taip pat nėra saulėlydis, bet REST tikrai bus populiarus tarp kūrėjų bendruomenės.
