Spørg to ingeniører, om du bør bruge gRPC eller REST, og du får tre svar, en benchmark og en stærk holdning til Protocol Buffers. Det meste af den diskussion handler om det forkerte.
Sammenligningen af protokollerne er reel nok. gRPC kører på HTTP/2 med binære Protobuf-beskeder og er målbart hurtigere over netværket. REST kører på almindelig HTTP med JSON, som enhver ingeniør kan læse i en browserfane. Men vi har siddet på begge sider af denne beslutning på klientplatforme, og det, der reelt afgør sagen, er sjældent latenstid. Det er, hvem der kalder dit API, og hvad dit team har ressourcer til at vedligeholde ved siden af.
Denne guide dækker de forskelle, der betyder noget, benchmark-tallene og hvad de udelader, hvad det reelt koster at indføre gRPC, samt en ramme for at træffe beslutningen. Kort fortalt: REST ud mod kanten, gRPC internt, og vær ærlig omkring dit kaldvolumen, før du binder dig.
Kort sagt:
API står for Application Programming Interface. Det er et software-bindeled: Det fastsætter reglerne for, hvordan to applikationer kommunikerer med hinanden, sender en anmodning fra en bruger til et system og bringer systemets svar tilbage.
Forestil dig, at du booker et hotel. Du åbner bookingsiden på din bærbare computer, siden sender din anmodning afsted til en server, og serveren henter dataene, finder ud af, hvad du har bedt om, udfører det og sender svaret tilbage til din skærm. Hver eneste af disse overleveringer sker via en API. Siden rører aldrig hotellets database, på samme måde som du aldrig selv går ind på bagkontoret for at tjekke værelseslisten.
En API definerer også, hvilke typer anmodninger én applikation kan sende til en anden: hvordan de skal foretages, hvilke dataformater der skal bruges, og hvilke konventioner brugerne skal følge.
I en monolitisk applikation ligger al funktionalitet i en enkelt kodebase. En mikrotjeneste-arkitektur opdeler dette i mindre tjenester, der kommunikerer via protokoller som HTTP. Disse tjenester taler sammen gennem API'er. Fjern API'erne, og en mikrotjeneste-arkitektur er blot en samling programmer, der ikke kan nå hinanden.
Der findes tre primære modeller til opbygning af en API: RPC (Remote Procedure Call), REST (Representational State Transfer) og GraphQL. Denne guide fokuserer på de to første.
RPC benytter en klient-server-model. Den anmodende server – klienten – sender en besked, som RPC oversætter og sender videre til en anden server. Denne server modtager anmodningen og sender svaret tilbage. Mens kaldet behandles, er klienten blokeret, og al beskedudveksling mellem serverne forbliver skjult.
RPC gør det muligt for klienten at anmode om en funktion i et bestemt format og modtage svaret i nøjagtig samme format. Den metode, der kaldes, er placeret i URL'en. Det fungerer til fjernprocedurekald i både lokale og distribuerede miljøer.
Ligesom et REST API fastlægger RPC reglerne for interaktion: hvordan en bruger sender kald for at aktivere metoder og interagere med tjenesten.
REST er en arkitektonisk stil frem for en protokol. Svar når frem til klienter som JSON eller XML, og modellen mapper konventionelt til HTTP-verber – selvom intet i REST specifikt kræver HTTP/1.1, og REST over HTTP/2 fungerer upåklageligt.
Når et REST API er offentligt tilgængeligt, præsenteres hver tjeneste i applikationen for forbrugeren som en ressource, der kan tilgås via de velkendte kommandoer: GET, POST, PUT og DELETE.
gRPC står for Google Remote Procedure Call, en variant bygget på RPC-arkitekturen. Den bruger HTTP/2 som transportlag, men HTTP bliver aldrig præsenteret for hverken API-udvikleren eller serveren. Du behøver ikke bekymre dig om, hvordan RPC-koncepter mappes til HTTP-verber og statuskoder. Det fjerner et helt lag af kompleksitet.
Formålet med gRPC er at flytte data mellem tjenester hurtigere. Det fungerer ved at definere en tjeneste og derefter fastlægge dens metoder, parametre og returtyper, så de kan kaldes eksternt.
Den udtrykker denne model i et IDL (interface description language). Som standard er IDL'et Protocol Buffers, som beskriver både tjenestens interface og strukturen af de meddelelser, der sendes.
Nu hvor vi har overblikket, er det her, de to for alvor adskiller sig.
REST-API'er følger en request-response-model, der oftest er bygget på HTTP/1.1. Hvis en tjeneste modtager flere anmodninger fra flere klienter, håndterer den dem én ad gangen, hvilket får hele systemet til at blive langsommere pga. køen. REST kan godt køre over HTTP/2, men request-response-modellen forbliver den samme, hvilket forhindrer den i at udnytte fordelene ved HTTP/2 fuldt ud.
gRPC er bygget på HTTP/2 og kan håndtere flere anmodninger fra forskellige klienter samtidigt ved at streame information kontinuerligt. Den håndterer også unary-interaktioner — en enkelt anmodning besvaret med et enkelt svar, hvilket er måden, alle REST-kald fungerer på.
Så gRPC dækker unary-interaktioner og tre former for streaming:
Dette er REST's største fordel. REST understøttes af alle browsere. Det gør gRPC ikke: det kræver gRPC-Web samt et proxylag til at oversætte mellem HTTP/1.1 og HTTP/2, hvilket er grunden til, at gRPC typisk anvendes i interne og private systemer.
Denne proxy er ikke bare en fodnote. Det er en komponent, som dit team skal installere, konfigurere, overvåge og betale for at køre, og som ligger på stien for enhver browseranmodning. Envoy er standarden, og den har et dedikeret gRPC-Web-filter for at udføre opgaven.
Der er en anden hage, som de fleste sammenligninger udelader. gRPC-Web understøtter ikke klient-side eller tovejs-streaming — kun server-streaming. Så i det øjeblik en browser er involveret, er den streaming-fordel, der oftest fremhæves til fordel for gRPC, halveret.
gRPC bruger som standard Protocol Buffers til at serialisere payload-data. Det er lettere, fordi formatet er kompakt, og meddelelserne bliver mindre. Protobuf er binært, og disse stærkt typede meddelelser konverteres automatisk til det sprog, som klienten og serveren er skrevet i.
REST baserer sig primært på JSON eller XML. REST kræver ikke nogen bestemt struktur, og JSON vandt på fleksibilitet: Det kan håndtere dynamiske data uden at kræve en streng form. Det er også læsbart for mennesker, hvilket Protobuf ikke er. Tænk på JSON som en pakke med indholdet skrevet udenpå med håndskrift, og Protobuf som den samme pakke med en stregkode. Den ene kan du læse med et hurtigt blik. Den anden læser maskinen øjeblikkeligt, men du skal bruge en scanner.
Den læsbarhed har en pris. JSON er ikke lige så let eller hurtigt at overføre, fordi det skal serialiseres og konverteres til det sprog, der bruges i begge ender. Det er et ekstra skridt i processen og endnu et sted, hvor tingene kan gå galt.
REST — en ressource og en form, du udleder af svaret:
GET /api/v1/bookings/8f2c1e HTTP/1.1
Host: api.example.com
Accept: application/json{
"id": "8f2c1e",
"guestName": "A. Fernandes",
"roomType": "double",
"checkIn": "2026-08-14",
"nights": 3,
"totalCents": 42000,
"currency": "EUR"
}Intet forhindrer en tjeneste i at tilføje discountCents næste tirsdag, og intet forhindrer en klient i stille og roligt at ignorere det faktum, at totalCents nu betyder noget lidt andet.
gRPC — kontrakten er en fil, og den eksisterer, før nogen af siderne er skrevet:
syntax = "proto3";
package booking.v1;
service BookingService {
rpc GetBooking (GetBookingRequest) returns (Booking);
rpc WatchAvailability (AvailabilityRequest) returns (stream AvailabilityUpdate);
}
message GetBookingRequest {
string booking_id = 1;
}
message Booking {
string booking_id = 1;
string guest_name = 2;
RoomType room_type = 3;
string check_in = 4; // ISO-8601 date
uint32 nights = 5;
Money total = 6;
// field 7 was `total_cents`, removed in v1.4 — never reuse the number
reserved 7;
reserved "total_cents";
}
enum RoomType {
ROOM_TYPE_UNSPECIFIED = 0;
ROOM_TYPE_SINGLE = 1;
ROOM_TYPE_DOUBLE = 2;
}To linjer dér udfører arbejde, som REST-versionen ikke kan. stream på WatchAvailability definerer streaming-casen i kontrakten i stedet for at tilføje den efterfølgende med polling eller en websocket. Og reserved 7 er versionsargumentet i en nøddeskal: det feltnummer kan aldrig genbruges, så en klient, der er kompileret mod det gamle skema, kan ikke uden videre læse det nye forkert. Kompileren håndhæver det, som REST overlader til en konvention, som nogen skal huske.
Prisen er synlig i det samme uddrag. Den fil skal kompileres, versionsstyres og distribueres til enhver forbruger, før nogen overhovedet kan foretage et enkelt kald – og intet af det kan læses i en browserfane.
REST-API'er har ingen indbygget kodegenerering. Udviklere benytter tredjepartsværktøjer som Swagger eller Postman til at generere forespørgselskode eller arbejder ud fra det framework, de allerede bruger.
gRPC genererer kode nativt gennem sin protoc kompiler, som understøtter en lang række sprog. Det betyder mest i systemer, hvor tjenester er skrevet i forskellige sprog på forskellige platforme. Den samme generator gør det også væsentligt mindre besværligt at bygge en SDK.
Begge kører over TLS, så ingen af dem er i sagens natur mere sikre på transportlaget, og gRPC har indbygget understøttelse af TLS og token-baseret godkendelse. Forskellen ligger i alt det udenom. REST arver hele HTTP-sikkerhedsøkosystemet: API-gateways, webapplikationsfirewalls, OAuth-flows og rate-limitere forstår det hele direkte ud af boksen.
gRPC kræver værktøjer, der taler HTTP/2 og Protobuf for at udføre det samme arbejde. Der findes gateway-understøttelse, men udvalget er mindre. Og et inspektionslag, der ikke kan læse en binær payload, kan ikke håndhæve regler for, hvad der er indeni.
REST læner sig op ad HTTP-statuskoder, som ethvert klientbibliotek, log-aggregator og overvågningsværktøj allerede taler. En 404 betyder det samme overalt.
gRPC definerer sine egne statuskoder, såsom NOT_FOUND og DEADLINE_EXCEEDED. De er mere detaljerede til service-til-service-kald, og de ligger uden for det HTTP-ordforråd, som dine eksisterende værktøjer er bygget op omkring. At tage gRPC i brug betyder, at du skal lære din overvågningsstak et ekstra sprog for fejl.
Det er her, en kontrakt-først tilgang virkelig viser sit værd. Protobuf identificerer felter via numre frem for navne, så tilføjelse af et felt er bagudkompatibelt fra starten, og ældre klienter ignorerer blot det, de ikke genkender. Skemaet er kontrakten, og compileren kontrollerer den.
REST tilbyder ingen tilsvarende garanti. Kompatibilitet afhænger af disciplin: versionsstyrede URL'er, klienter der er skrevet til at ignorere ukendte felter, og en konvention, som alle husker at følge. Det virker. Men intet håndhæver det.
Et REST-kald kan inspiceres med curl, en browserfane eller en loglinje af hvem som helst, helt uden forberedelse. Det kan et gRPC-kald ikke. Nyttelasten er binær, så du skal bruge et værktøj som grpcurl og den korrekte proto-fil, før du kan læse den.
Den forskel dukker aldrig op i en benchmark. Den dukker op en fredag aften, når man ser på, hvor lang tid det tager en on-call ingeniør at finde ud af, hvad en fejlbehæftet forespørgsel rent faktisk indeholdt.
Forskellene koncentrerer sig om tre områder: latenstid, payload-størrelse og gennemløb.
Om payload-størrelse. En uafhængig benchmark af JSON-kompatible binære serialiseringsspecifikationer viste, at Protocol Buffers opnåede en gennemsnitlig størrelsesreduktion på omkring 67 % i forhold til det bedste scenarie for komprimeret JSON: med stor spredning og tilfælde, hvor Protobuf endte med at være større. Det er værd at dvæle ved, da de tal, der cirkulerer om, at "Protobuf er ti gange mindre", næsten altid sammenligner med ukomprimeret JSON. Aktivér gzip på dine REST-endpoints, så mindskes forskellen markant uden videre.
Om svartid. Niswar et al. (2024) benchmarkede REST, GraphQL og gRPC på tværs af tre containeriserede Go-mikrotjenester og målte svartid og CPU-forbrug ved belastninger på 100 til 500 anmodninger, hvor der blev hentet både flade og indlejrede data. gRPC leverede de hurtigste svartider af de tre; GraphQL brugte mest CPU. Bemærk belastningsintervallet: Dette er en undersøgelse af hundredvis af anmodninger, ikke hundredtusindvis.
Om samtidighed. Googles egen gRPC-dokumentation rapporterer lavere svartider og højere effektivitet i miljøer med høj samtidighed, hvilket tilskrives HTTP/2-multiplexing. Da det er leverandørdokumentation, bør den læses som vejledende snarere end neutral.
gRPC er generelt mere effektivt end REST i miljøer med høj belastning og lav latenstid. REST er stadig fuldt ud tilstrækkeligt til almindelige webbaserede interaktioner.
Et forbehold, der er værd at bide mærke i. Gevinsterne er pr. kald, så de akkumuleres med volumen. På en tjeneste, der håndterer en håndfuld forespørgsler i sekundet, er forskellen reel, men fuldstændig irrelevant. På en tjeneste, der håndterer tusindvis, er det forskellen på, om man skal købe ekstra kapacitet i dette kvartal eller ej.
At se, hvordan hver stilart fungerer i produktion, gør valget tydeligere end nogen funktionsliste.
Intern kommunikation mellem tjenester. Backend-systemer, hvor ydeevne og effektivitet er kritiske, og begge ender af kaldet ejes af den samme organisation. Gevinsten er reduceret latenstid og effektiv binær kommunikation, og den bliver tydeligere i takt med kaldsvolumen.
Streaming i realtid. Live-datastrømme, chatsystemer og handelsplatforme, hvor tovejs-streaming er defineret i kontrakten frem for at være improviseret oven på polling. Husk begrænsningen for gRPC-Web nævnt ovenfor, hvis en browser er i den ene ende.
Mobil og IoT. Mindre payloads betyder mest, hvor båndbredden er begrænset eller afregnes efter forbrug: mobile klienter med dårlige forbindelser og enheder, der sender hyppige, små beskeder.
Offentlige API'er og tredjepartsintegrationer. Eksterne udviklere har allerede REST-værktøjer installeret og REST-viden i baghovedet. Hver eneste friktion, du tilføjer ved grænsefladen, betales af nogen, der endnu ikke har valgt din løsning.
CRUD-baserede applikationer. Standard create, read, update og delete-operationer uden krav om streaming. gRPC tilføjer unødig kompleksitet her uden at give nævneværdig værdi.
Enklere arkitekturer. Hvor brugervenlig implementering, læsbarhed og fleksibilitet ved ansættelser betyder mere end gennemløb – hvilket gælder for de fleste teams det meste af tiden.
| Egenskab | REST | gRPC | Bedste valg |
|---|---|---|---|
| Arkitekturstil | Ressourcebaseret kommunikation | Fjernprocedurekald mellem tjenester | Afhænger af systemdesign |
| Dataformat | Som regel JSON | Protocol Buffers som standard | REST for læsbarhed, gRPC for effektivitet |
| Transport | Transportuafhængig; normalt HTTP/1.1, fungerer over HTTP/2 | Bygget på HTTP/2 | gRPC for hastighed og multiplexing |
| Ydeevne | God til almindelige webanvendelsessager | Typisk hurtigere med mindre nyttelast | gRPC |
| Streamingunderstøttelse | Begrænset, normalt anmodning-svar | Klient, server og bidirektionel | gRPC (men se gRPC-Web-forbeholdet) |
| Browserunderstøttelse | Fremragende og universel | Kræver gRPC-Web og en proxy | REST |
| Nem fejlfinding | Inspicer med standardværktøjer | Binær nyttelast kræver dedikerede værktøjer | REST |
| Sikkerhedsværktøjer | Fungerer med eksisterende gateways, WAF'er og OAuth | Kræver HTTP/2- og Protobuf-tilpassede værktøjer | REST |
| Versionsstyring | Konventionsbaseret, kræver disciplin | Skemabaseret, bagudkompatibel pr. design | gRPC |
| Læringskurve | Lavere | Højere | REST for nemmere indførelse |
| Bedste anvendelsessager | Offentlige API'er, webapps, integrationer | Mikrotjenester, interne systemer, realtid | REST eksternt, gRPC internt |
De fleste sammenligninger af dette emne stopper ved selve protokollen og lader dig selv finde ud af de forretningsmæssige aspekter. For den, der skal godkende beslutningen, ligger omkostningerne fire steder, og ikke ét af dem optræder i en benchmark.
Proxylaget. Browserklienter kræver gRPC-Web og en proxy til at oversætte mellem HTTP/1.1 og HTTP/2. Det er infrastruktur, der skal konfigureres, overvåges, sikres og betales for, og som ligger på stien for hver eneste forespørgsel. REST kræver intet af dette.
Teamets kompetencer. Indlæringskurven er stejlere, og det handler ikke kun om protokollen. Det er workflowet omkring skemaer, den genererede kode i din build-pipeline og det ekstra sæt statuskoder, som din overvågningsstak skal lære at kende. Budgettér med opstartsfasen, ikke kun selve implementeringen.
Support og tid til fejlfinding. Binære payloads er uigennemskuelige uden det rette værktøj og den rette proto-fil. Usynligt i en projektplan. Ekstremt synligt under en hændelse.
Migrering. At tilføje gRPC til en eksisterende REST-arkitektur betyder, at man skal køre begge dele, mens tjenester flyttes, og betale for oversættelsen imellem dem, indtil de er færdige. Mellemtilstanden er den dyre del, og den varer lige så længe, som det tager din langsomste tjeneste at flytte.
Overfor alt dette står gevinsten, og den skalerer med den interne trafik. Besparelsen er pr. kald, så en tjeneste, der håndterer tusindvis af forespørgsler i sekundet, tjener investeringen hurtigt hjem, mens en tjeneste, der kun håndterer få dusin, måske aldrig tjener den hjem. Hvis jeres interne kaldvolumen er beskeden, og jeres team er trygt ved REST, er det ærlige svar, at gRPC vil koste jer mere, end det giver igen.
Tid til værdi fungerer på samme måde. REST når hurtigere frem til en første fungerende integration, fordi værktøjerne allerede findes på alle maskiner i huset. gRPC tager længere tid at sætte op og betaler sig først senere — i form af gennemløb og kontrakter, der fejler ved kompilering frem for i produktion.
Begge kan løse lignende problemer. De er optimeret til forskellige situationer.
Brug REST, når:
Brug gRPC, når:
Brug begge, når:
Denne hybridløsning bliver mere og mere almindelig, fordi den lader teams balancere fleksibilitet, ydeevne og nem integration uden at gå på kompromis med nogen af delene.
Læs nu de tre lister igen. Kun den midterste handler reelt om hastighed. De to andre handler om, hvem der står i den anden ende af kaldet, hvilket er grunden til, at det bedre spørgsmål ikke er, hvilken protokol der er hurtigst. Det er, hvem der bruger dette API.
Begge har deres anvendelsesmuligheder. gRPC er fremragende i højtydende miljøer, understøtter tovejs-streaming og bruger Protocol Buffers til effektiv serialisering. REST er enklere, mere fleksibelt og bedre egnet til webapplikationer og til kommunikation med en bred vifte af klienter, som du ikke selv har kontrol over.
REST, eller Representational State Transfer, er en arkitekturstil til opbygning af webtjenester. Den bruger standard HTTP-metoder som GET, POST, PUT og DELETE til kommunikation mellem klienter og servere. REST er kendt for sin enkelhed og tilstandsløshed – hver anmodning indeholder alt, hvad serveren skal bruge for at svare – hvilket gør den velegnet til webapplikationer og mikrotjenester. Den bruger typisk JSON eller XML til dataudveksling.
gRPC er et open source-framework udviklet af Google til højtydende kommunikation mellem tjenester. Det bruger HTTP/2 til transport og Protocol Buffers til serialisering, og understøtter både unary-kald samt server-, klient- og tovejs-streaming.
De væsentligste forskelle ligger i transport, dataformat, kontraktstyring og streaming. gRPC bruger HTTP/2 og Protobuf, hvilket giver mindre payloads, et compiler-håndhævet skema og tovejs-streaming. REST bruger almindeligvis HTTP/1.1 med JSON eller XML og fokuserer på tilstandsløs kommunikation og ressourcemanipulation via standard HTTP-verber. REST er lettere at forbruge og debugge; gRPC er hurtigere og mere stringent.
Nej. gRPC er generelt hurtigere takket være HTTP/2 og Protobuf, men forskellen afhænger af payload-størrelse, netværksforhold og om du har aktiveret komprimering på REST-siden. Benchmarks, der sammenligner Protobuf med ukomprimeret JSON, overdriver ofte forskellen. Ved lave anmodningsvolumener er forskellen målbar, men i praksis irrelevant.
Ikke direkte. Browsere kræver gRPC-Web samt en proxy som f.eks. Envoy til at oversætte mellem HTTP/1.1 og HTTP/2. gRPC-Web understøtter desuden kun server-streaming – ingen klient- eller tovejs-streaming – så nogle af gRPC's primære fordele går tabt i browseren.
Ja. Det er i aktiv udvikling og er særligt populært i arkitekturer med mikrotjenester, hvor ydeevne og effektiv kommunikation er afgørende. Understøttelse af mange sprog og platforme gør det fortsat populært i cloud-native økosystemer.
Ydeevne, effektivitet og understøttelse af flere sprog, samt en kontrakt-først arbejdsgang, der fanger breaking changes ved kompilering frem for i produktion. For store tjenestelandskaber med mange sprog fjerner kodegenerering fra et delt skema en hel kategori af integrationsarbejde.
Der findes ikke et standardtal, da omkostningerne afhænger af, hvor mange tjenester du flytter, og hvor længe de to stilarter skal køre sideløbende. Den største udgift er normalt overgangsperioden frem for selve implementeringen, da du betaler for at oversætte mellem REST og gRPC, indtil migreringen er afsluttet. Vurder migreringen ud fra det interne kaldvolumen først: Hvis det er lavt, kan gevinsten muligvis ikke retfærdiggøre skiftet.
gRPC er hurtigere på netværket og mere stringent omkring kontrakter. REST er lettere at forbruge, debugge og rekruttere folk til. Valget afgøres mindre af benchmarks og mere af, hvem der kalder dit API, og hvad dit team har ressourcer til at vedligeholde.
Hvis du overvejer dette til en platform, du er ved at bygge eller skalere, tager vi gerne en snak om det – også om de dele, som et benchmark ikke dækker. Fortæl os om dit projekt så fortæller vi dig, hvad vi ville gøre.
Marketing praktikant med særlig interesse for teknologi og forskning. I min fritid spiller jeg volleyball og forkæler min hund så meget som muligt.
Din daglige webudvikler, der kan lide at gemme sig i backend. Javascript og Ruby er min marmelade. Jeg fumler stadig med Docker, og mine bygninger går i stykker ret ofte.
People who read this post, also found these interesting:
.webp)
