Når du arbeider med API-er, vil du ofte støte på begrepene REST og gRPC. REST har lenge dominert dette feltet, men gRPC fremstår nå som en seriøs konkurrent.
REST og gRPC representerer to distinkte tilnærminger til API-design. API-er fungerer som en bro for kommunikasjon mellom ulike tjenester. Disse tjenestene kan være deler av komplekse systemer som befinner seg på forskjellige maskiner eller er utviklet med ulike programmeringsspråk.
Denne artikkelen gir en introduksjon til både REST og gRPC. Vi vil utforske deres likheter og forskjeller, samt se på hvilke bruksområder som passer best for hver av dem.
Hva er REST?
REST (Representational State Transfer) er en arkitekturstil som definerer regler for hvordan programvarekomponenter utveksler data. REST er bygget på den standardiserte kommunikasjonsprotokollen HTTP, som brukes på internett.
API-er som er basert på REST-arkitektur, kalles RESTful API-er. Tilsvarende kalles webtjenester som følger denne designen for RESTful webtjenester.
REST-arkitekturen er styrt av følgende prinsipper:
- Enhetlig grensesnitt: Serveren skal overføre data i et standardformat. Det er likevel ikke et krav at dataformatet som sendes, skal være det samme som det formatet serverapplikasjonen bruker internt.
- Tilstandsløshet: Hver enkelt klientforespørsel skal behandles uavhengig av serveren, uten at det tas hensyn til tidligere forespørsler. Forespørsler om ressurser kan komme i hvilken som helst rekkefølge, og hver forespørsel behandles isolert.
- Lagdelt system: Mellom klienten og serveren kan det ligge et lag av autoriserte mellomledd. Klienten kan koble seg til disse mellomleddene og likevel motta svar fra serveren.
- Hurtigbuffer: Noen svar kan lagres i en mellommann eller på klientsiden for å forbedre responstiden.
- Kode på forespørsel: Serveren kan tilpasse eller utvide klientens funksjonalitet ved midlertidig å overføre programvarekode til klienten.
Fordeler med REST
- Skalerbarhet: REST API-er er kjent for sin gode skalerbarhet, da de er optimalisert for interaksjoner mellom klient og server. Hurtigbuffer og tilstandsløshet er nøkkelfunksjoner som bidrar til å redusere belastningen på serveren.
- Fleksibilitet: RESTful API-er tilbyr full separasjon mellom klient og server. Dette forenkler utviklingen av serverkomponenter, som kan utvikles uavhengig av hverandre.
- Uavhengighet: Det er mulig å utvikle server- og klientapplikasjoner i ulike programmeringsspråk, uten at dette påvirker API-designet.
Bruksområder for REST
- Web API-er
- Webtjenester
- Mikrotjenestearkitektur
Hva er gRPC?
gRPC er et RPC-rammeverk (Remote Procedure Call) som er fleksibelt og kan benyttes i en rekke miljøer. Dette rammeverket er basert på åpen kildekode og er designet for høy ytelse, slik at tjenester kan kobles effektivt sammen både på tvers og innenfor datasentre.
En klientapplikasjon kan påkalle en metode i en serverapplikasjon som befinner seg på en annen maskin, på samme måte som om det var et lokalt objekt. Med gRPC definerer du en tjeneste og spesifiserer hvilke metoder som kan kalles eksternt, sammen med deres parametere og returtyper.
gRPC har integrert støtte for helsesjekker, autentisering, lastbalansering og sporing. Rammeverket bruker HTTP/2 og protokollbuffere for dataoverføring. Ved datautveksling utføres en prosedyre i stedet for en ressurs-URL.
Fordeler med gRPC
- Skalerbarhet: gRPC muliggjør rask oppsett av kjøretidsmiljøer og lar deg skalere til millioner av RPC-er per sekund.
- Enkel tjenestedefinisjon: Ved hjelp av Protocol Buffers kan du enkelt definere tjenestene dine og få dem til å fungere.
- Plattformuavhengighet: Rammeverket genererer klient- og server-stubber som er tilpasset ulike plattformer og programmeringsspråk.
- Toveis strømming og integrert autentisering.
Bruksområder for gRPC
- Web API-er
- Webtjenester
- Strømmeapplikasjoner
- Mikrotjenestekommunikasjon
Likheter mellom REST og gRPC
- Mekanisme for datautveksling: Begge arkitekturstilene legger til rette for datautveksling mellom servere og klienter. Utvekslingen er basert på gitte regler.
- Egnet for skalerbare og distribuerte systemer: Både REST og gRPC sin asynkrone kommunikasjon og tilstandsløse design gjør det enkelt å skalere API-ene.
- HTTP-basert kommunikasjon: Begge benytter HTTP, som er den mest brukte kommunikasjonsprotokollen på internett.
- Fleksibilitet: REST og gRPC kan brukes med ulike programmeringsspråk og teknologier.
REST vs. gRPC: En dypere sammenligning
Det er flere forskjeller mellom REST- og gRPC-tjenester:
Datautveksling
I REST API-er må data som sendes mellom programvarekomponenter, uttrykkes i JSON-format. JSON må serialiseres og oversettes til et bestemt programmeringsspråk før datautveksling. REST API-er kan også utveksle andre dataformater, som HTML og XML.
gRPC bruker som standard Protocol Buffers-formatet. Den støtter imidlertid også JSON. Protokollbuffere er ikke lesbare for mennesker. Serveren bruker et grensesnittbeskrivelsesspråk for å definere en datastruktur, og gRPC serialiserer deretter denne strukturen til et binært format. Dataene blir deretter deserialisert til det valgte programmeringsspråket.
Kommunikasjonsmodell
I REST sender klienten en enkelt forespørsel til serveren, som svarer med et enkelt svar. Klienten må vente på serverens respons før operasjonen kan fortsette. Dette kalles en forespørsel-svar-modell.
I gRPC kan klienten sende en eller flere forespørsler til serveren, som kan svare med ett eller flere svar. Datatilkoblinger kan være mange-til-mange, mange-til-en, en-til-mange eller en-til-en. gRPC bruker en klient-server kommunikasjonsmodell.
Kodegenerering
gRPC har innebygde funksjoner for generering av kode på både server- og klientsiden. Disse funksjonene finnes i forskjellige språk, med hjelp fra Protocol Buffers-kompilatoren. gRPC genererer koden etter at datastrukturen er definert i en protofil.
REST mangler innebygde funksjoner for kodegenerering. Hvis du trenger dette, må du benytte tredjepartsverktøy.
HTTP-protokoll
REST API-er benytter HTTP 1.1. For å sende en forespørsel til en REST-tjeneste trenger du en ressurs-URL. HTTP 1.1 sender informasjon mellom en datamaskin og en webserver. I REST-tjenester er ressurs-URLen synlig for klienten, og API-designerne kontrollerer strukturen til ressurs-URLene.
gRPC benytter HTTP/2. Denne HTTP-versjonen ble introdusert i 2015 og brukes av nettlesere som Internet Explorer, Safari og Chrome. I motsetning til HTTP 1.1, som holder all informasjon i ren tekst, bruker HTTP/2 binærformatinnkapsling, noe som gir flere dataleveringsalternativer og øker hastigheten på prosessen.
Datastruktur for nyttelast
REST bruker XML eller JSON for å sende og motta data. JSON er det vanligste formatet for dynamiske data i REST, da det er fleksibelt og ikke krever noen bestemt struktur. JSON-data er også lesbare for mennesker. Ulempen med JSON er at det ikke er så raskt, da det må serialiseres og oversettes under dataoverføring.
gRPC bruker Protocol Buffers for å serialisere nyttelastdata. Dette er et høyt komprimert format som reduserer mengden data som sendes. Rammeverket bruker Protobuf for automatisk å konvertere sterkt innskrevne meldinger til klientens og serverens programmeringsspråk.
Nettleserstøtte
REST støttes av alle nettlesere da det bruker HTTP 1.1. Dette gjør det til et godt valg for webtjenester og API-er.
gRPC har begrenset støtte for nettlesere da det er basert på HTTP/2. For å støtte alle nettlesere, må du legge til gRPC-web som et proxy-lag. gRPC er derfor mest brukt internt i systemer.
Klient-server-kobling
REST er designet for løs kobling. Dette betyr at klienten og serveren ikke trenger detaljert kunnskap om hverandres implementasjoner. Denne egenskapen gjør det enklere å utvikle et RESTful API over tid, da du ikke behøver å endre klientkoden når du endrer serverdefinisjoner.
gRPC er tett koblet, og serveren og klienten må ha tilgang til den samme protofilen. Hvis det gjøres endringer i filen, må både server og klient oppdateres.
REST vs. gRPC
| Funksjon | REST | gRPC |
| HTTP-protokoll | HTTP 1.1 | HTTP/2 |
| Nettleserstøtte | Støtter alle nettlesere ettersom den bruker HTTP 1.1 | Mindre nettleserstøtte ettersom den bruker HTTP/2 |
| Kodegenerering | Bruker tredjepartsverktøy | Innebygde kodegenereringsfunksjoner |
| Designtilnærming | Enhetsorientert design | Tjenesteorientert tilnærming |
| Datatilgang | Ressurs-URL-er | Tjenesteoppkall |
| Implementering | REST implementeres direkte på klient- eller serversiden | gRPC-programvare er nødvendig både på klient- og serversiden. |
| Kommunikasjonsmodell | En enkelt klient kommuniserer med en enkelt server | Flere kommunikasjonsmodeller, f.eks. en klient sender forespørsler til flere servere |
Når bør du bruke REST?
RESTful API-er og webtjenester er svært populære. RESTful-tjenester er enkle å implementere, gir struktur til data, er fleksible og lesbare. Du kan vurdere å bruke REST i følgende situasjoner:
- Nettbaserte arkitekturer: Du kan lage web-, mobil- og plattformuavhengige API-er ved å bruke REST.
- Enkel datakommunikasjon: REST bruker JSON, et lettlest dataformat.
- Offentlige API-er: Hvis dataene og API-et ditt er ment for offentlig bruk, er REST et godt valg på grunn av lesbarheten.
Når bør du bruke gRPC?
gRPC er ikke like utbredt som RESTful-tjenester. Det har imidlertid unike funksjoner som gjør det velegnet i følgende situasjoner:
- Flerspråklige systemer: gRPC passer godt i mikrotjenestearkitekturer som er skrevet i ulike programmeringsspråk, og der API-et trolig ikke vil endre seg.
- Mikrotjenestekoblinger: Toveis strømming og begrenset nettleserstøtte gjør gRPC til et godt valg for interne API-er.
- Sanntidsstrømming: Du kan bruke gRPC med interne tjenester som håndterer store datamengder og krever sanntidsstrømming.
Forfatternes mening
Selv om gRPC har spesifikke funksjoner som kan overskygge REST i applikasjoner som Internet of Things, vinner REST på grunn av sin lesbarhet, fleksibilitet og utbredte bruk. gRPCs begrensete nettleserstøtte gjør det mindre egnet for utviklere som ønsker å bygge webtjenester.
Den universelle støtten for RESTful-tjenester gjør REST til det ideelle valget for API-er for web- og mikrotjenesteintegrasjoner.
Konklusjon
REST og gRPC er to av flere API-arkitekturstiler du kan velge når du bygger ditt neste API. Valget vil avhenge av produktet du ønsker å lage. RESTful-tjenester passer godt for offentlige API-er, mens gRPC er et godt valg for tjenester som mobilapplikasjoner som ikke krever nettleserstøtte.
Du kan lese vår artikkel om hvordan du lager en gRPC-tjeneste fra bunnen av ved hjelp av Java.