Hvilken du skal velge for ditt neste prosjekt [2023]

0 Shares

Du vil ofte møte REST og gRPC når du arbeider med APIer. Selv om Rest har dominert dette feltet i mange år, viser gRPC seg å være en verdig konkurrent.

Rest og gPRC er to forskjellige måter du kan designe et API på. API-er fungerer som en kommunikasjonsbro mellom tjenester som kan representere komplekse systemer som ligger på forskjellige datamaskiner eller skrevet på forskjellige språk.

Denne artikkelen vil introdusere både Rest og gRPC, dele deres likheter, forskjeller og hvor du kan bruke hver.

Hva er hvile?

Hvile (Representational State Transfer) er en arkitektonisk programvaretilnærming som dikterer regler for hvordan programvarekomponenter utveksler data. Resten er basert på nettets standard kommunikasjonsprotokoll, HTTP.

Alle API-ene basert på REST-arkitektonisk stil kalles RESTful API-er. På den annen side er webtjenester som følger REST arkitektonisk design kjent som RESTful webtjenester.

REST arkitektonisk stil er styrt av disse prinsippene;

Ensartet grensesnitt: Serveren skal overføre data i et standardformat. Dataene som transporteres kan imidlertid være i et annet format enn den interne representasjonen av serverapplikasjonens ressurs.
Statsløshet: Serveren skal fullføre hver klientforespørsel uavhengig, uavhengig av tidligere forespørsler. Klientforespørsler om ressurser kan være i hvilken som helst rekkefølge, og hver forespørsel er isolert fra resten.
Lagdelt system: Presenterer et lag med autoriserte mellomledd mellom serveren og klienten. Klienten kan koble seg til disse autoriserte mellommennene og fortsatt motta svar fra serveren.
Bufferbarhet: Noen svar lagres på en mellommann eller klienten for å forbedre responstiden.
Kode på forespørsel: Servere tilpasser eller utvider klientfunksjonaliteten midlertidig ved å overføre programvareprogrammeringskode til klienten.

Fordeler med REST

Skalerbar: REST API-er er kjent for sin skalerbarhet da de optimaliserer klient-server-interaksjoner. Buffer og tilstandsløshet er de viktigste funksjonene som reduserer serverbelastningen.
Fleksibel: RESTful APIer tilbyr total klient-server-separasjon. Slike tjenester vil koble fra og forenkle ulike serverkomponenter, som kan utvikle seg uavhengig.
Uavhengighet: Du kan skrive server- og klientapplikasjoner på forskjellige programmeringsspråk uten å påvirke API-designet.

API-arkitektur forklart på 5 minutter eller mindre

Bruk tilfeller av Rest

Web APIer
nettjenester
Mikrotjenester arkitektur

Hva er gRPC?

gRPC er et RPC-rammeverk (Remote Procedure Call) som kan kjøres i alle miljøer. Dette rammeverket med åpen kildekode er utformet som en høyytelsesprotokoll som effektivt kan koble tjenester på tvers av og i datasentre.

En klientapp kan kalle en metode på en serverapp på en annen maskin som om det var et lokalt objekt. Med gRPC definerer du en tjeneste og spesifiserer metodene du kan ringe eksternt med deres parametere og returtyper.

gRPC har pluggbar helsesjekking, autentisering, lastbalansering og sporingsstøtte. Dette rammeverket bruker HTTP 2 og protokollbuffere for dataoverføring. Når data utveksles, kalles en prosedyre i stedet for en ressurs-URL

Fordeler med gRPC

Skalerbar: gRPC lar deg installere kjøretidsmiljøer med en enkelt kommando og begynne å skalere millioner av RPCer/sekund.
Enkel tjenestedefinisjon: Bruk Protocol Buffers for å definere tjenestene dine og få dem til å kjøre.
Cross-platform: Dette rammeverket genererer idiomatiske klient- og serverstubber for forskjellige plattformer og språk.
Toveis streaming og integrert autentisering.

Bruk tilfeller av gRPC

Web APIer
nettjenester
Streaming-applikasjoner
Mikrotjenester kommunikasjon

Likheter mellom REST og gRPC

Datautvekslingsmekanisme: Begge arkitektoniske designene lar servere og klienter utveksle data. Imidlertid deles disse dataene basert på visse regler.
Egnet for skalerbare og distribuerte systemer: Den asynkrone kommunikasjonen og tilstandsløse utformingen av både REST og gRPC gjør det enkelt å skalere API-ene deres.
Bruk HTTP-basert kommunikasjon: Begge bruker HTTP, den mest foretrukne kommunikasjonsprotokollen på nettet.
Fleksibel: Du kan bruke REST og gRPC med forskjellige programmeringsspråk og teknologier.

REST vs. gRPC: Deep Dive Comparison

REST- og gRPC-tjenester er forskjellige på følgende måter;

Datautveksling

I REST APIer må data som sendes fra en programvarekomponent til en annen uttrykkes i JSON-format. JSON må serialiseres og oversettes til et programmeringsspråk for datautveksling. Imidlertid kan Rest APIer også utveksle dataformater som HTML og XML.

gRPC, som standard, bruker Protocol Buffers-formatet. Den støtter imidlertid også JSON. Protokollbuffere er ikke lesbare for mennesker. Serveren bruker Protocol Buffer-grensesnittbeskrivelsesspråk for å definere en datastruktur. gPRC serialiserer deretter datastrukturen til et binært format. Den vil deretter deserialisere dataene til alle spesifiserte programmeringsspråk.

Kommunikasjonsmodell

I REST sender en klient en enkelt forespørsel til en server; serveren sender deretter et svar som svar. Klienten må vente på serverens svar før operasjonen kan fortsette. Det er en forespørsel-svar-modell.

Hvordan lage Restore Health Potions i Skyrim

I gRPC kan en klient sende én eller flere serverforespørsler, noe som resulterer i henholdsvis enkelt eller flere svar. Datatilkoblinger kan være mange-til-mange, mange-til-én, én-til-mange eller én-til-én. gRPC bruker en klient-svar kommunikasjonsmodell.

Kodegenerering

gRPC har innebygde funksjoner for generering av kode på serversiden og klientsiden. Du kan finne disse funksjonene på forskjellige språk med tillatelse fra Protocol Buffers-kompilatoren. gRPC genererer koden på serversiden og klientsiden etter å ha definert strukturen i protofilen.

REST mangler innebygde kodegenereringsfunksjoner. Hvis du trenger denne funksjonen, kan du bruke tredjepartsverktøy.

HTTP-protokoll

REST API-er bruker HTTP 1.1. For å sende en forespørsel på en REST-tjeneste trenger du en ressurs-URL. HTTP 1 sender informasjon mellom en datamaskin og en webserver. Ressurs-URLen i REST-tjenesten er synlig for klienten. API-designerne kontrollerer strukturen til ressurs-URL-er.

gRPC bruker HTTP 2. Denne HTTP-versjonen ble introdusert i 2015 og brukes i nettlesere som Internet Explorer, Safari og Chrome. I motsetning til HTTP 1, som holder alt i ren tekst, bruker dette nyere formatet binærformatinnkapsling, noe som resulterer i flere dataleveringsalternativer og fremskynder hele prosessen.

Nyttelastdatastruktur

REST bruker XML eller JSON for å sende og motta data. JSON er det mest brukte formatet for å sende dynamiske data i REST da det er fleksibelt og ikke krever noen struktur. JSON-data er også lesbare for mennesker. Det eneste problemet med JSON er ikke så raskt, da det må serialiseres og oversettes under dataoverføring.

gRPC bruker Protocol Buffers for å serialisere nyttelastdata. Dette er et svært komprimert format som reduserer meldingsdataene. Dette rammeverket bruker Protobuf til automatisk å konvertere sterkt innskrevne meldinger til klientens og serverens programmeringsspråk.

Nettleserstøtte

REST støttes på alle nettlesere da den bruker HTTP 1.1. Dette gjør det til et perfekt valg for webtjenester og APIer.

gRPC har begrenset støtte for nettlesere da den er basert på HTTP 2. For å støtte alle nettlesere må du legge til gRPC-web som et proxy-lag. Av denne grunn er gRPC stort sett tatt i bruk for interne systemer.

Klient-server kobling

REST er en løst koblet arkitektonisk design. Det betyr at klienten og serveren ikke trenger å vite om hverandres implementeringer. Denne funksjonen gjør det lettere å utvikle en RESTful API over tid, siden du ikke trenger å endre klientkoden når du endrer serverdefinisjoner.

Hvordan fikse Microsoft Teams som sitter fast ved lasting

gRPC er et tett sammenkoblet rammeverk der serveren og klienten må ha tilgang til samme protofil. Hvis du trenger å gjøre endringer i filen, må du også oppdatere serveren og klienten.

Hvile vs. gRPC

FunksjonRESTgRPCHTTP-protokollHTTP 1.1HTTP 2Nettleserstøtte Støtter alle nettlesere ettersom den bruker HTTP 1.1 Mindre nettleserstøtte ettersom den bruker HTTP 2KodegenereringBruker tredjepartsverktøy Innebygde kodegenereringsfunksjonerDesigntilnærming Entitetsorientert designServiceorientert tilnærmingDatatilgangRessurs-URLerTjenesteoppkallingenidirekteprogramvareimplementeringIendirekteprogramvareimplementer REST på klienten eller server-sidegRPC-programvare er nødvendig både på klient- og serversiden. KommunikasjonsmodellEn enkelt klient kommuniserer med en enkelt serverFlere kommunikasjonsmodeller som en klient sender forespørsler til flere servere, en server som kommuniserer med flere klienter, eller en server som kommuniserer med en klient.

Når du skal bruke REST

RESTful APIer og webtjenester er veldig populære. RESTful-tjenester er enkle å implementere, strukturerer data, fleksible og lesbare. Du kan bruke REST i følgende tilfeller;

Nettbaserte arkitekturer: Du kan lage web-, mobil- og multiplattform-APIer ved å bruke REST-arkitektonisk design.
Enkel datakommunikasjon: REST bruker JSON, et lettlest dataformat.
Offentlige APIer: Hvis du har til hensikt at publikum skal konsumere data og bruke API-en din, vil REST være et godt valg på grunn av lesbarhetsfunksjonen.

Når du skal bruke gRPC

gRPC er ikke like populær som RESTful-tjenester. Den har imidlertid også unike funksjoner som vil få den til å skille seg ut i følgende applikasjoner;

Flerspråklige systemer: gRPC passer til mikrotjenestearkitekturer skrevet på forskjellige programmeringsspråk og hvor API-en neppe vil endres.
Mikrotjenester-tilkoblinger: Funksjoner som toveis streaming og lav nettleserstøtte gjør gRPC til et godt valg for interne APIer.
Strømnettverk i sanntid: Du kan bruke gRPC med interne tjenester som håndterer store databelastninger og krever strømming i sanntid.

Forfatternes mening

Selv om gRPC har noen spesifikke funksjoner som kan overskygge REST i applikasjoner som Internet of Things, vinner sistnevnte på grunn av sin lesbarhet, fleksibilitet og brede bruk. gRPCs lavere nettleserstøtte gjør det til et ikke så godt valg for utviklere som ønsker å bygge webtjenester.

Den universelle støtten for RESTful-tjenester gjør REST til den ideelle API-arkitektoniske stilen for web- og mikrotjenester-integrasjoner.

Konklusjon

REST og gRPC er blant de mange API-arkitektoniske stilene du kan velge når du bygger din neste API. Det endelige valget vil avhenge av produktet du vil bygge. RESTful-tjenester vil passe perfekt når du bygger offentlige API-er, mens gRPC er et godt valg for tjenester som mobilapplikasjoner som ikke krever nettleserstøtte.

Deretter kan du sjekke artikkelen vår om hvordan du lager gRPC fra bunnen av ved hjelp av Java.