Podatkovni modeli API-jev v oblaku niso samo izboljšali izkušnje v oblaku, temveč so razvijalcem in skrbnikom omogočili, da z uporabo teh API-jev vključijo delovne obremenitve v oblak. Za večino podjetij API-ji omogočajo izmenjavo informacij med različnimi krajevnimi aplikacijami in aplikacijami v oblaku. Prav tako igrajo pomembno vlogo za bolj nemoteno vključevanje obremenitev platforme. Ker sprejemanje oblakov še naprej narašča, je vse več povpraševanja po integracijskih točkah med aplikacijami znotraj in zunaj oblačnega okolja. Porast strategije večglasnega glasovanja skupaj s potrebo po izboljšanju zmogljivosti med oblaki so povečali odvisnost od okolja API v oblaku. Kateri pristop pa je boljši in kakšno podporo dobite v svojem oblačnem okolju?
MILO na kratko
SOAP (okrajšava za Simple Object Access Protocol), starejši pristop, je imel podporo v celotni industriji, od proizvodnih podjetij, kot sta IBM in Microsoft, do izvajalcev storitev. Priložen je tudi obsežen, a zapleten sklop standardov. Microsoftova ekipa, ki je oblikovala SOAP, je naredila izjemno prilagodljivo - za komunikacijo prek zasebnih omrežij, interneta in e-pošte. Podprlo ga je tudi več standardov. Začetna različica SOAP je bila del specifikacije, ki je vsebovala tudi univerzalni opis, odkrivanje in integracijo (UDDI) ter jezik za opis spletnih storitev (WSDL).
SOAP v bistvu zagotavlja ovoj za pošiljanje sporočil spletnih storitev. Sama arhitektura je zasnovana tako, da pomaga pri izvajanju različnih operacij med programi. Komunikacija med programi običajno poteka prek zahtev na osnovi XML in odgovorov na podlagi HTTP. HTTP se večinoma uporablja komunikacijski protokol, lahko pa se uporabljajo tudi drugi protokoli.
Sporočilo SOAP vsebuje nekatere obvezne dele, kot so KOVERTA
, GLAVA
, TELO
, in NAPAKA
. TheKOVERTA
objekt definira začetek in konec zahteve za sporočilo XML, GLAVA
vsebuje vse elemente glave, ki jih strežnik obdela, in TELO
vsebuje preostali objekt XML, ki predstavlja zahtevo. NAPAKA
object uporablja katero koli obdelavo napak.
POČITEK
REST (Reprezentativni državni prenos) se običajno imenuje arhitekturni slog in ne protokol, ki se uporablja za izdelavo spletnih storitev. Arhitektura REST omogoča komunikacijo med dvema programoma, pri čemer lahko en program zahteva in manipulira z viri od drugega. Zahteva REST za dostop do virov v ciljnem programu uporablja glagole HTTP: GET
, OBJAVI
, PUT
, in IZBRIŠI
. Te zahteve lahko uporabljajo format podatkov, vključno z XML, HTML in JSON. JSON je najbolj zaželen, saj je najbolj združljiv in enostaven za uporabo. večina API-jev REST temelji na URI-jih (enotni identifikator vira) in so specifični za protokol HTTP.
REST je razvijalcem prijazen, saj je s preprostejšim slogom lažji za uporabo in uporabo kot SOAP. REST je manj podroben in med komunikacijo med dvema končnima točkama se pošlje manj podatkov.
Zakaj MILO ali POČITEK?
Medtem ko je SOAP kot pri uporabi ovojnice, ki vsebuje veliko informacij o obdelavi, REST lahko štejemo za razglednico, ki ima URI kot ciljni naslov, je lahka in jo je mogoče predpomniti. REST temelji na podatkih in se primarno uporablja za dostop do vira (URI) za nekatere podatke; SOAP je protokol, ki temelji na funkcijah. REST omogoča prilagodljivost pri izbiri oblike podatkov (navadno besedilo, HTML, XML ali JSON), medtem ko SOAP uporablja samo XML.
SOAP je primeren za aplikacije, kjer potrebujete višjo raven varnosti. SOAP ima varnostne funkcije na ravni podjetja, ki jih podpira WS-Security, skupaj s podporo SSL. Če želite razviti rešitev za mobilno bančništvo, bi bili API-ji SOAP verjetno prvi premislek glede varnostnih zahtev. SOAP ponuja tudi logiko ponovnega poskusa za zagotovljen uspeh in zanesljivo komunikacijo. REST uporablja HTTP in lahko odpravi napake v komunikaciji samo s ponovnim poskusom, vendar logika ponovnega poskusa ni vgrajena v REST. SOAP zagotavlja vgrajeno logiko ponovnega poskusa.
Kaj se spremeni v okolju, ki je izvorno za oblake?
Z vidika razvijalca se pri izbiri med REST ali SOAP v resnici nič ne spremeni, toda oblikovanje vaše storitve v okolju, ki temelji na oblaku, upošteva perspektivo platforme. Razpoložljivost storitev in odzivni čas igrata ključno vlogo pri oblikovanju poslovnih storitev in domačih aplikacij v oblaku. Z varnostnega vidika se v računalništvu v oblaku široko uporablja protokol WS-Security (Web Service Security), ki zagotavlja celovito zaščito sporočil z uporabo sporočil SOAP, da zaščiti varnost večine spletnih storitev, povezanih z računalništvom v oblaku. Toda WS-Security uporablja elemente glave SAOP za prenos informacij, povezanih z varnostjo. Sporočilo SOAP je v obliki zapisa XML in je običajno veliko večje kot dejansko sporočilo v binarni obliki. To podaljša čas in obdelavo za sporočanje in obdelavo podatkov. To je lahko argument razprave za izbiro REST v primerjavi s SOAP, vendar se premik s SOAP na REST ne glede na platformo, na kateri bo vaša aplikacija delovala.
Konec leta 2016 je Microsoft Azure dodal podporo za prehod SOAP za upravljanje API-jev Azure, ki razvijalcem pomaga ustvariti strežnik proxy za svoje API-je SOAP na enak način, kot ustvarijo strežnik za API-je REST / HTTP. S podporo za prehod SOAP lahko uvozite dokumente WSDL in ustvarite nov proxy API; postopek preuči vsa dejanja SOAP v dokumentu in jih učinkovito ustvari v končne točke API. V prihodnji različici bomo morda videli funkcijo, ki je potrebna za ustvarjanje REST front end z uporabo SOAP back end.
V svetu AWS je večina API-jev AWS dostopna samo prek REST in ima omejeno podporo za SOAP. Viri EC2 so na voljo prek REST ali Query API, medtem ko je API SOAP za EC2 zastarel od konca leta 2015. Storitve, kot sta Amazon S3 in RDS, podpirajo tudi REST, medtem ko je SOAP podprt samo prek HTTPS; SOAP za HTTP je zastarel. Amazon SQS ne podpira SOAP več. Čeprav se zdi, da REST vodi API-je AWS, se Amazon API Gateway integrira z ekosistemom AWS in nudi podporo pri ustvarjanju, upravljanju in uvajanju API-ja RESTful, da razkrije končne točke HTTP / HTTPS, funkcije AWS Lambda in / ali druge storitve AWS. API Gateway prav tako pomaga priklicati izpostavljene metode API prek čelnih končnih točk HTTP.
Vse več podpore se nagiba k API-jem RESTful. Zaradi enostavnosti z glagolskimi operacijami je prijazen do razvijalcev. Združljiv je z večino formatov in je enostaven za uporabo. Tudi za SOAP ni sončnega zahoda, zagotovo pa bo REST priljubljen med skupnostjo razvijalcev.