Programmering

REST eller SOAP i et cloud-native miljø

Cloudbaserede API-datamodeller har ikke kun forbedret skyoplevelsen, men også givet udviklere og administratorer en måde at integrere arbejdsbelastninger i skyen ved hjælp af disse API'er. For de fleste virksomheder tillader API'er at dele information på tværs af forskellige lokale og skybaserede applikationer. De spiller også en vigtig rolle for at integrere platformens arbejdsbelastning mere problemfrit. Da cloudoptagelse fortsætter med at vokse, er der mere efterspørgsel efter integrationspunkter mellem applikationer i og uden for skymiljøet. Stigningen af ​​multicloud-strategi sammen med behovet for forbedring af cross cloud-kapaciteter har øget afhængigheden af ​​cloud-API-miljø. Men hvilken tilgang er bedre, og hvilken støtte får du i dit skymiljø?

Sæbe i en nøddeskal

SOAP (forkortelse for Simple Object Access Protocol), den ældre tilgang, havde support i hele verden lige fra produktvirksomheder som IBM og Microsoft til serviceimplementører. Det fulgte også med et omfattende, men komplekst sæt standarder. Microsoft-team, der designede SOAP, gjorde det til at være ekstremt fleksibelt - at kunne kommunikere via private netværk på tværs af internettet og e-mails. Det blev også understøttet af flere standarder. Den oprindelige version af SOAP var også en del af en specifikation, der også indeholdt Universal Description, Discovery and Integration (UDDI) og Web Services Description Language (WSDL).

SOAP giver i det væsentlige konvolutten til afsendelse af webtjenestemeddelelser. Selve arkitekturen er designet til at hjælpe med udførelsen af ​​forskellige operationer mellem softwareprogrammer. Kommunikation mellem programmer sker normalt via XML-baserede anmodninger og HTTP-baserede svar. HTTP er mest brugt kommunikationsprotokol, men andre protokoller kan også bruges.

En SOAP-meddelelse indeholder nogle obligatoriske dele som f.eks KUVERT, HEADER, LEGEMEog FEJL. DetKUVERT objekt definerer starten og slutningen af ​​XML-meddelelsesanmodning, HEADER indeholder alle headerelementer, der skal behandles af serveren, og LEGEME indeholder det resterende XML-objekt, der udgør anmodningen. FEJL objekt bruges enhver fejlhåndtering.

HVILE

REST (repræsentativ statsoverførsel) betegnes normalt som en arkitektonisk stil snarere end en protokol, der bruges til at opbygge webtjenester. REST-arkitektur tillader kommunikation mellem to softwareprogrammer, hvor det ene program kan anmode om og manipulere ressourcer fra det andet. REST-anmodning om adgang til ressourcer på målprogrammet bruger HTTP-verber: , STOLPE, SÆTTEog SLET. Disse anmodninger kan bruge dataformat inklusive XML, HTML og JSON. JSON er mest foretrukket, da det er mest kompatibelt og let at bruge. de fleste REST API'er er baseret på URI'er (Uniform Resource Identifier) ​​og er specifikke for HTTP-protokol.

REST er udviklervenligt, fordi dets enklere stil gør det lettere at implementere og bruge end SOAP. REST er mindre detaljeret, og mindre datamængde sendes, når der kommunikeres mellem to slutpunkter.

Hvorfor sæbe eller hvile?

Mens SOAP er som at bruge en konvolut, der indeholder masser af behandlingsoplysninger inde i den, kan REST betragtes som et postkort, der har en URI som destinationsadresse, er let og kan cachelagres. REST er datadrevet og bruges primært til at få adgang til en ressource (URI) til bestemte data; SOAP er en protokol, der er funktionsdrevet. REST giver fleksibilitet i valg af dataformat (almindelig tekst, HTML, XML eller JSON), mens SOAP kun bruger XML.

SOAP er velegnet til applikationer, hvor du har brug for højere sikkerhedsniveau. SOAP leveres med sikkerhedsfunktioner på virksomhedsniveau understøttet af WS-Security sammen med SSL-support. Hvis du ønsker at udvikle en mobilbankløsning, vil SOAP API'er sandsynligvis være den første overvejelse for sikkerhedskrav. SOAP giver også en forsøgslogik for garanteret succes og pålidelig kommunikation. REST bruger HTTP og kan kun tackle kommunikationsfejl ved at prøve igen, men retry-logikken følger ikke med REST. SOAP leverer indbygget forsøgslogik.

Hvad ændrer sig i et cloud-native miljø?

Fra en udviklerperspektiv ændres intet virkelig i valget mellem REST eller SOAP, men at designe din service i et cloud-native miljø bringer platformsperspektiv i betragtning. Servicetilgængelighed og svartid spiller en kritisk rolle i design af virksomhedstjenester og cloud-native applikationer. Fra et sikkerhedsmæssigt synspunkt anvendes WS-Security (Web Service Security) -protokol, der giver end-to-end beskedniveau sikkerhed ved hjælp af SOAP-meddelelser, i vid udstrækning i cloud computing for at beskytte sikkerheden for de fleste cloud computing relaterede webtjenester. Men WS-Security bruger SAOP-headerelementer til at overføre sikkerhedsrelaterede oplysninger. En SOAP-meddelelse er af XML-format og er normalt meget større i størrelse end den aktuelle meddelelse i et binært format. Dette øger tiden og behandlingen til at kommunikere og behandle dataene. Dette kan være diskussionsargument for valg af REST versus SOAP, men der skiftes fra SOAP til REST uanset hvilken platform din applikation vil køre på.

Sent i 2016 tilføjede Microsoft Azure SOAP-gennemgangssupport til Azure API Management, der hjælper udviklere med at oprette en proxy til deres SOAP API'er på samme måde, som de opretter proxy til REST / HTTP API'er. Ved hjælp af SOAP passthrough support kan du importere WSDL-dokumenter og oprette en ny API-proxy; processen ser på alle SOAP-handlinger i dokumentet og opretter effektivt dem til API-slutpunkter. I en fremtidig version ser vi muligvis en funktion, der anmodes om at oprette REST-frontend ved hjælp af en SOAP-backend.

Inde i AWS-verdenen er de fleste AWS API'er kun tilgængelige via REST og har begrænset support til SOAP. EC2-ressourcer er tilgængelige via REST eller Query API, mens SOAP API til EC2 er udfaset siden slutningen af ​​2015. Tjenester såsom Amazon S3 og RDS understøtter også REST, mens SOAP kun understøttes via HTTPS; SOAP for HTTP er udfaset. Amazon SQS understøtter ikke SOAP længere. Mens REST ser ud til at lede AWS API'er, integreres Amazon API Gateway med AWS-økosystemet og yder support ved oprettelse, styring og implementering af en RESTful API for at eksponere back-end HTTP / HTTPS-slutpunkter, AWS Lambda-funktioner og / eller andre AWS-tjenester. API Gateway hjælper også med at påkalde eksponerede API-metoder gennem front-end HTTP-slutpunkter.

Mere og mere support læner sig mod RESTful API'er. Dens enkelhed med verb-lignende operationer gør det udviklervenligt. Den er kompatibel med de fleste formater og er nem at bruge. Der er heller ingen solnedgang for SOAP, men REST vil bestemt være populær blandt udviklerfællesskabet.

$config[zx-auto] not found$config[zx-overlay] not found