Vil du linke din app til Facebook, så den kan generere opslag automatisk, eller til Instagram, så du kan genposte billeder med bestemte hashtags?
Du kan også ønske at inkludere YouTube-videoer på dit websted. Applikationsprogrammeringsgrænseflader giver dig mulighed for at udføre alle disse opgaver og mere (API'er).
Forskellige applikationer kan "tale" til hinanden på en sikker og standardiseret måde takket være API'er som Instagram API, Facebook API og YouTube API.
Med andre ord kan et program tage funktioner eller data fra et andet stykke software og bruge dem til at forbedre sine egne funktioner eller brugeroplevelse. Men hvordan kan apps fremsætte disse anmodninger, behandle dem og svare på dem på en måde, som andre kan forstå?
Det afhænger af, hvordan API'en blev oprettet. Når man diskuterer API-design (applikationsprogrammeringsgrænseflade), er det normalt at sammenligne SOAP vs. REST, to af de mest fremtrædende API-paradigmer.
Så snart SOAP API'er (Simple Object Access Protocol) blev guldstandarden for virksomheder som Oracle, Sun og PayPal, var der et lige og modsat svar et år eller deromkring senere mod REST API'er fra Google, Amazon og eBay.
I dette indlæg vil vi sammenligne og sammenligne SOAP API'er med REST API'er, så du kan beslutte, hvilken der er bedst til dine formål.
Vi vil begynde med at definere API.
Hvad er API?
Application Programming Interface omtales som API. API'er er i bund og grund en samling af metoder og funktioner, der muliggør udvikling af apps. De får adgang til oplysninger og funktioner i forskellige programmer, tjenester eller operativsystemer.
De fungerer som en slags mellemmand mellem forskellige softwaresystemer. De muliggør "snak" mellem to ikke-forbundne programmer.
Lad os tage eksemplet med en børsmægler, der er aktivt involveret i handel og de finansielle markeder. En samling af automatiserede handelsalgoritmer kan forbindes til den erhvervsdrivendes foretrukne handelsmæglerplatform gennem en API. Dette gør det muligt for dig, den erhvervsdrivende, at udføre elektroniske transaktioner eller se realtidstilbud og prisdata.
Hvad er REST?
Ægte "webtjenester" API'er inkluderer REST (Representational State Transfer). REST API'er er bygget på URI'er (Uniform Resource Identifiers, hvoraf en URL er en speciel type), HTTP-protokollen og det utroligt browser-kompatible JSON-dataformat.
SOAP-protokollen, som vi allerede har nævnt, kan muligvis også bruges. REST API'er kan være nemme at skabe og vokse, men de kan også være enorme og svære – det hele afhænger af, hvordan de er oprettet, udvidet, og hvad de er beregnet til at gøre.
Ressourcebegrænsninger, reducerede sikkerhedskrav, browserklientkompatibilitet, opdagelse, datasundhed og skalerbarhed er nogle af grundene til, at du ønsker at udvikle en API til at være RESTful – ting, der faktisk gælder for webtjenester.
REST tilbyder en mere let mulighed. SOAP var svært at bruge og belastende for mange udviklere. For eksempel kræver brug af SOAP med JavaScript, at der skrives en masse kode for at udføre simple operationer, da den nødvendige XML-struktur skal oprettes hver gang.
REST bruger (typisk) en ligetil URL i stedet for en XML-anmodning. Selvom der er sjældne omstændigheder, hvor du skal tilbyde flere detaljer, bruger størstedelen af RESTful webtjenester kun URL-teknikken.
De fire HTTP 1.1 verber GET, POST, PUT og DELETE kan bruges af REST til at udføre operationer. I modsætning til SOAP behøver REST ikke at svaret er i XML.
REST-baserede webtjenester, der udsender data i Command Separated Value (CSV), JavaScript Object Notation (JSON) og Really Simple Syndication (RSS) formater er tilgængelige (RSS).
Målet er, at du kan få de resultater, du har brug for, i et let-at-parse format inden for det sprog, du bruger til din applikation.
Funktionalitet
- REST understreger enkelhed frem for alt andet på grund af HTTP-protokoller.
- Nettet er bedst egnet til REST. Det er kompatibelt med browsere, fordi JSON bruges som dataformat.
- REST er kendt for sin enestående skalerbarhed og hastighed.
- Klient-serverforbindelser og arkitekturer gøres mere tilgængelige af REST API'er. Hvis det er RESTful, er det konstrueret ved hjælp af denne klient-server-model, med rundrejser mellem de to parter, der passerer datanyttelast.
- REST API'er anvender en enkelt standardgrænseflade. Ved at sikre, at alle apps forbinder ensartet og gennem den samme gateway, strømlines, hvordan applikationer kommunikerer med API'en.
Hvad er SOAP?
Dens egen protokol, kaldet SOAP (Simple Object Access Protocol), er lidt mere kompliceret end REST, da den specificerer flere standarder, herunder dem, der er relateret til sikkerhed og levering af beskeder.
Disse iboende normer kommer med en lille smule ekstra overhead. De kan dog være en afgørende faktor for virksomheder, der har brug for mere omfattende sikkerheds-, transaktions- og ACID-overholdelseskapaciteter (Atomicitet, Konsistens, Isolation, Durability).
Af hensyn til denne sammenligning er det vigtigt at bemærke, at mange af fordelene ved SOAP ikke ofte gælder for webserviceapplikationer, hvilket gør dem mere velegnede til virksomhedsscenarier.
Højere grader af sikkerhed (såsom når en Mobile App interagerer med en bank), beskedapps, der kræver pålidelig kommunikation, interaktion med ældre systemer eller ACID-overholdelse er et par grunde til, at du ønsker at designe en applikation, der bruger en SOAP API.
De beskedfunktioner, der tilbydes af SOAP, er udelukkende baseret på XML. Ældre internet-inkompatible teknologier som Distributed Component Object Model (DCOM) og Common Object Request Broker Architecture blev erstattet af SOAP, da den først blev skabt af Microsoft (CORBA).
Afhængigheden af binær kommunikation får disse systemer til at fejle. Over internettet fungerer XML-meddelelser som dem, der bruges af SOAP, bedre.
Funktionalitet
- Sikkerheden i SOAP er væsentligt strammere. WS-Security er en indbygget standard, der tilbyder SOAP yderligere sikkerhedsfunktioner på virksomhedsniveau, hvis det er nødvendigt ud over SSL-understøttelse.
- Vellykket/genforsøg begrundelse for pålidelig meddelelsesydelse. Fordi REST mangler en standardiseret meddelelsesmekanisme, kan den kun prøve igen, når kommunikationen fejler. Selv når der bruges SOAP-mellemprodukter, tilbyder SOAP ende-til-ende pålidelighed på grund af dens indbyggede logik for succes/genforsøg.
- SOAP overholder allerede ACID-standarder. Ved at diktere, hvordan transaktioner kan interagere med databasen, minimerer ACID-overholdelse uregelmæssigheder og sikrer sammenhængen i en database. Fordi ACID er mere forsigtig end andre datakonsistensmodeller, bruges det ofte til håndtering af følsomme transaktioner, uanset om de er finansielle eller på anden måde.
- Det er nemt for programmører at forstå, da SOAP er en fuldstændig XML-baseret kommunikation.
- XML-meddelelsesprotokollen er en tilføjelse til HTTP-protokollen.
- Kommunikation fra en computer til en anden computer kan formidles via SOAP-meddelelser.
- Klient-server-arkitektur kan også implementeres. En SOAP-protokolmeddelelse kan bruges af klienten til at kalde et fjernprocedurekald, der er placeret på serversiden.
HVILE Vs SÆBE forskelle
1. arkitektur
En API er beregnet til primært at vise specifikke komponenter af en applikations forretningslogik på en server. Mens REST gør brug af URI'er til samme formål, anvender SOAP en Service Interface til dette.
REST API'er oprettes efter dataene, hvorimod SOAP API'er udvikles efter de funktionaliteter, som API'en illustrerer. Sammenlignet med SOAP, som er mere funktionsdrevet, er REST et mere datadrevet design.
2. Caching
Data, der er blevet markeret som cachebare, kan bruges af browsere igen, uden at de skal lave en ny anmodning til serveren. At spare tid og kræfter er en fordel ved dette.
Svar cachelagres ikke på HTTP-niveau, da SOAP-forespørgsler sendes via POST-anmodninger, som HTTP-standarden anser for ikke-idempotente. Hvis du vil bruge caching, skal du stadig bygge de nødvendige teknikker, da REST API'er ikke inkluderer denne implementering.
3. Ressourcer og båndbredde
På grund af den konvolutagtige nyttelastoverførsel, der bruges af SOAP, er der en beskeden stigning i overhead, hvilket nødvendiggør ekstra båndbredde. RESTs lette natur er en fordel i disse situationer, fordi det generelt bruges til webtjenester.
4. Sikkerhed
WS-sikkerhed, som SOAP understøtter og er lidt mere grundig end SSL på transportniveau, er ønskelig. At inkorporere sikkerhedsforanstaltninger på virksomhedsniveau med det er også en perfekt pasform.
End-to-end-kryptering ved hjælp af SSL understøttes af både SOAP og REST, og REST kan bruge HTTPS, den sikre variant af HTTP-protokollen.
5. Håndtering af nyttelast
Data, der overføres via internettet, kaldes en nyttelast. En nyttelast, der anses for "tung", har brug for yderligere ressourcer. Sammenlignet med SOAP, som bruger XML, bruger REST ofte JSON og HTTP til at hjælpe med at reducere nyttelasten.
Et specialiseret klientbibliotek med genereret kode skal typisk bruges af klienten til at få adgang til SOAP API'er på grund af deres ekstremt stringente kommunikationskontrakt.
Som et resultat tilbyder SOAP et mindre abstraktionsniveau end REST og er tættere forbundet med serveren.
Hvornår skal man bruge REST?
- Oprettelse af offentlige API'er: REST API'er foretrækkes til at bygge offentlige webtjenester, fordi de anses for at være enklere at bruge og adoptere end SOAP API'er. Derudover tilbyder SOAP flere indbyggede sikkerhedsforanstaltninger, som REST ikke har, selvom disse egenskaber ikke er påkrævet, når man arbejder med åbne data og tjenester.
- Konstruktion af mobile apps: REST er perfekt til at bygge mobile applikationer, da den er lille, effektiv, statsløs og cachebar.
- Udnyttelse af knappe serverressourcer og båndbredde: Alle anmodninger til en REST API skal være statsløse, hvilket betyder, at hver interaktion er separat, og hver anmodning og svar indeholder alle de data, der er nødvendige for at fuldføre denne interaktion. Serveren gemmer ikke registreringer af tidligere anmodninger, da den behandler hver enkelt som en ny anmodning. Som et resultat kræver serveren langt mindre hukommelse og fungerer hurtigere, fordi en anmodning ikke kræver yderligere handling eller hentning af historiske data.
Hvornår skal man bruge SOAP?
- Oprettelse af private API'er, især til store virksomheder: SOAP er perfekt til virksomhedsapplikationer, da det muliggør dataflow i et decentraliseret, distribueret miljø og indeholder flere online sikkerhedsfunktioner.
- Brug af en anden transportprotokol end HTTP som det underliggende lag: SOAP er ikke afhængig af HTTP som det underliggende lag. Afhængigt af dit program kan du bruge SMTP (Simple Mail Transfer Protocol), JMS (Java Messaging Service) eller en anden transportprotokol.
- Arbejder med stateful operations: I modsætning til anmodninger til REST API'er er anmodninger til SOAP API'er stateful, hvilket betyder, at serveren gemmer information om klienten og bruger den på tværs af en kæde af anmodninger eller operationer. Selvom dette bruger mere serverbåndbredde og ressourcer, er det afgørende for at udføre rutinemæssige eller forbundne handlinger, såsom bankoverførsler.
Konklusion
Sammenligningen mellem REST og SOAP API'er gør det helt tydeligt, at REST er at foretrække frem for SOAP. Alligevel er der situationer, hvor SOAP API er påkrævet. I visse tilfælde oprettes webtjenester ved at kombinere REST og SOAP API'er.
Derfor vil use casen afgøre, hvilken API-stil der fungerer bedst.
Giv en kommentar