Cloud-baserte API-datamodeller har ikke bare forbedret skyopplevelsen, men også gitt en måte for utviklere og administratorer å integrere arbeidsmengder i skyen ved hjelp av disse API-ene. For de fleste bedrifter lar API-er dele informasjon på tvers av ulike lokale og skybaserte applikasjoner. De spiller også en viktig rolle for å integrere arbeidsmengder på plattformer mer sømløst. Etter hvert som adopsjon av skyer fortsetter å vokse, er det større etterspørsel etter integreringspunkter mellom applikasjoner i og utenfor skymiljøet. Fremveksten av multicloud-strategi sammen med behovet for forbedring av cross cloud-funksjoner har økt avhengigheten av API-miljøet i skyen. Men hvilken tilnærming er bedre og hvilken støtte får du i skymiljøet ditt?
Såpe i et nøtteskall
SOAP (forkortelse for Simple Object Access Protocol), den eldre tilnærmingen, hadde bransjestøtte, alt fra produktselskaper som IBM og Microsoft til serviceimplementører. Den fulgte også med et omfattende, men likevel komplisert sett med standarder. Microsoft-teamet som designet SOAP gjorde det til å være ekstremt fleksibelt - å kunne kommunisere over private nettverk, over internett og e-post. Det ble støttet av flere standarder også. Den første versjonen av SOAP var en del av en spesifikasjon som også inneholdt UDDI (Universal Description, Discovery and Integration) og WSDL (Web Services Description Language).
SOAP gir i hovedsak konvolutten for sending av nettjenestemeldinger. Arkitekturen i seg selv er designet for å hjelpe ytelsen til forskjellige operasjoner mellom programvareprogrammer. Kommunikasjon mellom programmer skjer vanligvis via XML-baserte forespørsler og HTTP-baserte svar. HTTP er mest brukt protokoll for kommunikasjon, men andre protokoller kan også brukes.
En SOAP-melding inneholder noen obligatoriske deler som KONVOLUTT, OVERSKRIFT, KROPP, og FEIL. DeKONVOLUTT objektet definerer starten og slutten av XML-meldingsforespørsel, OVERSKRIFT inneholder topptekstelementer som skal behandles av serveren, og KROPP inneholder det gjenværende XML-objektet som utgjør forespørselen. FEIL objektet brukes enhver feilhåndtering.
HVILE
REST (Representational State Transfer) blir vanligvis referert til som en arkitektonisk stil i stedet for en protokoll, som brukes til å bygge webtjenester. REST-arkitektur tillater kommunikasjon mellom to programmer, hvor det ene programmet kan be om og manipulere ressurser fra det andre. REST-forespørsel om tilgang til ressurser på målprogrammet bruker HTTP-verb: FÅ, POST, SETTE, og SLETT. Disse forespørslene kan bruke dataformat inkludert XML, HTML og JSON. JSON er mest foretrukket siden den er mest kompatibel og enkel å bruke. de fleste REST APIer er basert på URI (Uniform Resource Identifier) og er spesifikke for HTTP-protokoll.
REST er utviklervennlig fordi den enklere stilen gjør det enklere å implementere og bruke enn SOAP. REST er mindre ordentlig, og mindre datamengde sendes når du kommuniserer mellom to sluttpunkter.
Hvorfor såpe eller hvile?
Mens SOAP er som å bruke en konvolutt som inneholder mye behandlingsinformasjon i den, kan REST betraktes som et postkort som har en URI som destinasjonsadresse, er lett og kan caches. REST er datadrevet og brukes primært for å få tilgang til en ressurs (URI) for visse data; SOAP er en protokoll som er funksjonsstyrt. REST gir fleksibilitet i valg av dataformat (ren tekst, HTML, XML eller JSON) mens SOAP bare bruker XML.
SOAP passer godt for applikasjoner der du trenger høyere sikkerhetsnivå. SOAP kommer med sikkerhetsfunksjoner på bedriftsnivå som støttes av WS-Security, sammen med SSL-støtte. Hvis du ønsker å utvikle en mobilbankløsning, vil SOAP API-er trolig være den første vurderingen for sikkerhetskrav. SOAP gir også en prøvelogikk for garantert suksess og pålitelig kommunikasjon. REST bruker HTTP og kan bare løse kommunikasjonsfeil ved å prøve på nytt, men logg på nytt prøver ikke innebygd med REST. SOAP gir innebygd logg på nytt.
Hva endrer seg i et skyinnfødt miljø?
Fra utviklerens perspektiv endres ingenting egentlig i å velge mellom REST eller SOAP, men å designe tjenesten din i et skyinnfødt miljø bringer plattformperspektiv i betraktning. Tjenestetilgjengelighet og responstid spiller en avgjørende rolle i utformingen av forretningstjenester og cloud native applikasjoner. Fra et sikkerhetsmessig synspunkt brukes WS-Security (Web Service Security) -protokoll, som gir end-to-end meldingsnivåsikkerhet ved bruk av SOAP-meldinger, mye i cloud computing for å beskytte sikkerheten til de fleste cloud computing-relaterte webtjenester. Men WS-Security bruker SAOP-headerelementer for å frakte sikkerhetsrelatert informasjon. En SOAP-melding er av XML-format og har vanligvis mye større størrelse enn den faktiske meldingen i binært format. Dette øker tiden og behandlingen for å kommunisere og behandle dataene. Dette kan være argument for debatt for å velge REST versus SOAP, men det er skifte fra SOAP til REST uavhengig av plattformen applikasjonen din vil kjøre på.
Sent i 2016 la Microsoft Azure til SOAP-gjennomgangsstøtte til Azure API Management som hjelper utviklere å lage en proxy for sine SOAP API-er på samme måte som de oppretter proxy for REST / HTTP API-er. Ved hjelp av SOAP-gjennomstøtingsstøtte kan du importere WSDL-dokumenter og opprette en ny API-proxy. prosessen ser på alle SOAP-handlinger i dokumentet og skaper dem effektivt til API-endepunkter. I en fremtidig versjon kan det hende vi ser en funksjon bedt om å opprette REST-frontend ved hjelp av en SOAP-backend.
Inne i AWS-verdenen er de fleste AWS API-er bare tilgjengelige via REST og har begrenset støtte for SOAP. EC2-ressurser er tilgjengelige via REST eller Query API, mens SOAP API for EC2 er avviklet siden slutten av 2015. Tjenester som Amazon S3 og RDS støtter også REST mens SOAP bare støttes via HTTPS; SOAP for HTTP er avviklet. Amazon SQS støtter ikke SOAP lenger. Mens REST ser ut til å lede AWS APIer, integreres Amazon API Gateway med AWS-økosystemet og gir støtte til å skape, administrere og distribuere en RESTful API for å eksponere back-end HTTP / HTTPS-sluttpunkter, AWS Lambda-funksjoner og / eller andre AWS-tjenester. API Gateway hjelper også med å påkalle eksponerte API-metoder gjennom frontend-HTTP-endepunktene.
Stadig mer støtte støtter seg mot RESTful APIer. Dens enkelhet med verblignende operasjoner gjør det utviklervennlig. Den er kompatibel med de fleste formater og er enkel å bruke. Det er ingen solnedgang for SOAP heller, men REST kommer definitivt til å være populært blant utviklerfellesskapet.
