Vil du koble appen din til Facebook slik at den kan generere innlegg automatisk, eller til Instagram slik at du kan legge ut bilder på nytt med bestemte hashtags?
Du kan også ønske å inkludere YouTube-videoer på nettstedet ditt. Applikasjonsprogrammeringsgrensesnitt lar deg utføre alle disse oppgavene og mer (API).
Ulike applikasjoner kan "snakke" til hverandre på en sikker og standardisert måte takket være APIer som Instagram API, Facebook API og YouTube API.
Med andre ord kan et program ta funksjoner eller data fra en annen programvare og bruke dem til å forbedre sine egne funksjoner eller brukeropplevelse. Men hvordan kan apper sende disse forespørslene, behandle dem og svare på dem på en måte som andre kan forstå?
Det avhenger av hvordan APIen ble opprettet. Når man diskuterer API-design (applikasjonsprogrammeringsgrensesnitt), er det vanlig å sammenligne SOAP vs. REST, to av de mest fremtredende API-paradigmene.
Så snart SOAP APIer (Simple Object Access Protocol) ble gullstandarden for firmaer som Oracle, Sun og PayPal, var det et likt og motsatt svar et år eller så senere mot REST APIer fra Google, Amazon og eBay.
I dette innlegget vil vi sammenligne og kontrastere SOAP APIer med REST APIer slik at du kan bestemme hvilken som er best for dine formål.
Vi begynner med å definere API.
Hva er API?
Application Programming Interface omtales som API. APIer er i hovedsak en samling av metoder og funksjoner som muliggjør utvikling av apper. De får tilgang til informasjonen og funksjonene til forskjellige programmer, tjenester eller operativsystemer.
De fungerer som en slags mellommann mellom ulike programvaresystemer. De gjør det mulig å "snakke" mellom to ukoblede programmer.
La oss ta eksemplet med en aksjemegler som er aktivt involvert i handel og finansmarkedene. En samling av automatiserte handelsalgoritmer kan kobles til traderens favoritt handelsmeglerplattform gjennom en API. Dette gjør det mulig for deg som trader å utføre elektroniske transaksjoner eller se sanntidstilbud og prisdata.
Hva er REST?
Ekte "webtjenester" APIer inkluderer REST (Representational State Transfer). REST APIer er bygget på URIer (Uniform Resource Identifiers, hvorav en URL er en spesiell type), HTTP-protokollen og det utrolig nettleserkompatible JSON-dataformatet.
SOAP-protokollen, som vi allerede har sagt, kan muligens også brukes. REST API-er kan være enkle å lage og vokse, men de kan også være enorme og vanskelige – alt avhenger av hvordan de opprettes, utvides og hva de er ment å gjøre.
Ressursbegrensninger, reduserte sikkerhetskrav, nettleserklientkompatibilitet, oppdagbarhet, datahelse og skalerbarhet er noen grunner til at du ønsker å utvikle et API for å være RESTful – ting som faktisk gjelder for webtjenester.
REST tilbyr et mer lett alternativ. SOAP var vanskelig å bruke og belastende for mange utviklere. For eksempel krever bruk av SOAP med JavaScript å skrive mye kode for å fullføre enkle operasjoner siden den nødvendige XML-strukturen må opprettes hver gang.
REST bruker (vanligvis) en enkel URL i stedet for en XML-forespørsel. Selv om det er sjeldne omstendigheter når du må tilby flere detaljer, bruker flertallet av RESTful-netttjenestene kun URL-teknikken.
De fire HTTP 1.1-verbene GET, POST, PUT og DELETE kan brukes av REST for å utføre operasjoner. I motsetning til SOAP, trenger ikke REST at svaret er i XML.
REST-baserte webtjenester som sender ut data i Command Separated Value (CSV), JavaScript Object Notation (JSON) og Really Simple Syndication (RSS) formater er tilgjengelige (RSS).
Målet er at du kan få resultatene du trenger i et format som er lett å analysere på språket du bruker for applikasjonen din.
Egenskaper
- REST legger vekt på enkelhet fremfor alt annet, på grunn av HTTP-protokoller.
- Nettet egner seg best for REST. Den er kompatibel med nettlesere fordi JSON brukes som dataformat.
- REST er kjent for sin enestående skalerbarhet og hastighet.
- Klient-server-tilkoblinger og arkitekturer gjøres mer tilgjengelige av REST APIer. Hvis det er RESTful, er det konstruert ved hjelp av denne klient-server-modellen, med rundturer mellom de to partene som passerer datanyttelast.
- REST API-er bruker et enkelt standardgrensesnitt. Ved å sikre at alle apper kobles jevnt og gjennom samme gateway, strømlinjeformer hvordan apper kommuniserer med API.
Hva er SOAP?
Dens egen protokoll, kalt SOAP (Simple Object Access Protocol), er litt mer komplisert enn REST siden den spesifiserer flere standarder, inkludert de som er knyttet til sikkerhet og meldingslevering.
Disse iboende normene kommer med litt ekstra overhead. Imidlertid kan de være en avgjørende faktor for virksomheter som trenger mer omfattende sikkerhet, transaksjoner og ACID (Atomicity, Consistency, Isolation, Durability) compliance-evner.
For denne sammenligningens skyld er det viktig å merke seg at mange av fordelene med SOAP ikke ofte gjelder webtjenester-applikasjoner, noe som gjør dem mer egnet for bedriftsscenarioer.
Høyere grader av sikkerhet (som når en mobile app samhandler med en bank), meldingsapper som krever pålitelig kommunikasjon, samhandling med eldre systemer eller ACID-overholdelse er noen få grunner til at du ønsker å designe en applikasjon som bruker en SOAP API.
Meldingsfunksjonene som tilbys av SOAP er utelukkende basert på XML. Eldre internett-inkompatible teknologier som Distributed Component Object Model (DCOM) og Common Object Request Broker Architecture ble erstattet av SOAP da den først ble opprettet av Microsoft (CORBA).
Avhengigheten av binær kommunikasjon fører til at disse systemene mislykkes. Over internett fungerer XML-meldinger som brukes av SOAP bedre.
Egenskaper
- Sikkerheten til SOAP er betydelig strammere. WS-Security er en innebygd standard som tilbyr SOAP ekstra sikkerhetsfunksjoner på bedriftsnivå ved behov i tillegg til SSL-støtte.
- Vellykket/forsøk på nytt resonnement for pålitelig meldingsytelse. Fordi REST mangler en standardisert meldingsmekanisme, kan den bare prøve på nytt når kommunikasjonen svikter. Selv når du bruker SOAP-mellomprodukter, tilbyr SOAP ende-til-ende-pålitelighet på grunn av sin innebygde logikk for vellykket/forsøk på nytt.
- SOAP overholder allerede ACID-standarder. Ved å diktere hvordan transaksjoner kan samhandle med databasen, minimerer ACID-overholdelse uregelmessigheter og sikrer konsistensen til en database. Fordi ACID er mer forsiktig enn andre datakonsistensmodeller, brukes den ofte ved håndtering av sensitive transaksjoner, enten de er økonomiske eller andre.
- Det er enkelt for programmerere å forstå siden SOAP er en fullstendig XML-basert kommunikasjon.
- XML-meldingsprotokollen er et tillegg til HTTP-protokollen.
- Kommunikasjon fra en datamaskin til en annen datamaskin kan spres via SOAP-meldinger.
- Klient-server-arkitektur kan også implementeres. En SOAP-protokollmelding kan brukes av klienten til å ringe et eksternt prosedyrekall som ligger på serversiden.
REST Vs SOAP Forskjeller
1. arkitektur
Et API er ment å primært vise spesifikke komponenter av forretningslogikken til en applikasjon på en server. Mens REST bruker URIer til samme formål, bruker SOAP et tjenestegrensesnitt for dette.
REST APIer opprettes etter dataene, mens SOAP APIer utvikles etter funksjonaliteten som APIen illustrerer. Sammenlignet med SOAP, som er mer funksjonsdrevet, er REST en mer datadrevet design.
2. caching
Data som er merket som bufret kan brukes av nettlesere igjen uten at de trenger å sende en ny forespørsel til serveren. Å spare tid og krefter er en fordel med dette.
Svar blir ikke bufret på HTTP-nivå siden SOAP-spørringer sendes via POST-forespørsler, som HTTP-standarden anser som ikke-idempotente. Hvis du vil bruke caching, må du fortsatt bygge de nødvendige teknikkene ettersom REST APIer ikke inkluderer denne implementeringen.
3. Ressurser og båndbredde
På grunn av den konvoluttaktige nyttelastoverføringen som brukes av SOAP, er det en beskjeden økning i overhead, noe som krever ekstra båndbredde. RESTs lette natur er en fordel i disse situasjonene fordi den vanligvis brukes til webtjenester.
4. Sikkerhet
WS-sikkerhet, som SOAP støtter og er litt mer grundig enn SSL på transportnivå, er ønskelig. Å inkludere sikkerhetstiltak på bedriftsnivå med den passer også perfekt.
End-to-end-kryptering med SSL støttes av både SOAP og REST, og REST kan bruke HTTPS, den sikre varianten av HTTP-protokollen.
5. Håndtering av nyttelast
Data som overføres via Internett omtales som en nyttelast. En nyttelast som anses som "tung" trenger ekstra ressurser. Sammenlignet med SOAP, som bruker XML, bruker REST ofte JSON og HTTP for å redusere nyttelasten.
Et spesialisert klientbibliotek med generert kode må vanligvis brukes av klienten for å få tilgang til SOAP APIer på grunn av deres ekstremt strenge kommunikasjonskontrakt.
Som et resultat tilbyr SOAP et lavere abstraksjonsnivå enn REST og er tettere knyttet til serveren.
Når skal man bruke REST?
- Opprette offentlige APIer: REST APIer foretrekkes for å bygge offentlige webtjenester fordi de anses å være enklere å bruke og ta i bruk enn SOAP APIer. I tillegg tilbyr SOAP flere innebygde sikkerhetstiltak som REST ikke har, selv om disse egenskapene ikke er nødvendige når du arbeider med åpne data og tjenester.
- Konstruere mobilapper: REST er perfekt for å bygge mobile applikasjoner siden den er liten, effektiv, statsløs og bufrbar.
- Utnytter knappe serverressurser og båndbredde: Alle forespørsler til en REST API må være statsløse, noe som betyr at hver interaksjon er separat og hver forespørsel og svar inneholder alle dataene som er nødvendige for å fullføre den interaksjonen. Serveren lagrer ikke registreringer av tidligere forespørsler siden den behandler hver enkelt som en ny forespørsel. Som et resultat krever serveren langt mindre minne og fungerer raskere fordi en forespørsel ikke krever ytterligere handling eller henting av historiske data.
Når skal man bruke SOAP?
- Opprette private APIer, spesielt for store bedrifter: SOAP er perfekt for bedriftsapplikasjoner siden den muliggjør dataflyt i et desentralisert, distribuert miljø og inneholder flere online sikkerhetsfunksjoner.
- Bruke en annen transportprotokoll enn HTTP som det underliggende laget: SOAP er ikke avhengig av HTTP som underliggende lag. Avhengig av applikasjonen din, kan du bruke SMTP (Simple Mail Transfer Protocol), JMS (Java Messaging Service) eller en annen transportprotokoll.
- Jobber med stateful drift: I motsetning til forespørsler til REST APIer, er forespørsler til SOAP APIer stateful, noe som betyr at serveren lagrer informasjon om klienten og bruker den på tvers av en kjede av forespørsler eller operasjoner. Selv om dette bruker mer serverbåndbredde og ressurser, er det avgjørende for å utføre rutinemessige eller koblede handlinger, som bankoverføringer.
konklusjonen
Sammenligningen mellom REST og SOAP APIer gjør det ganske tydelig at REST er å foretrekke fremfor SOAP. Likevel er det situasjoner der SOAP API er nødvendig. I visse tilfeller opprettes nettjenester ved å kombinere REST og SOAP APIer.
Derfor vil brukstilfellet avgjøre hvilken API-stil som vil fungere best.
Legg igjen en kommentar