REST API vs. GraphQL — forskjeller og når bør du velge hva?

Hva er REST og GraphQL — de grunnleggende forskjellene

REST (Representational State Transfer) er en arkitekturstil der data eksponeres som ressurser via URL-endepunkter. Et typisk REST API kan ha endepunkter som GET /users/42, POST /orders og DELETE /products/7. Hver ressurs har sin egen URL, og du bruker HTTP-metoder (GET, POST, PUT, DELETE) for å utføre operasjoner. REST er stateless — serveren lagrer ingen klienttilstand mellom forespørsler.

GraphQL er et spørrespråk for APIer utviklet av Facebook og åpen kildekode-publisert i 2015. I stedet for mange endepunkter har du ett enkelt endepunkt (vanligvis /graphql) der klienten spesifiserer nøyaktig hvilke data den trenger i spørringen. Serveren returnerer akkurat det — ikke mer, ikke mindre. GraphQL er sterkt typet og har et selvdokumenterende skjema (schema) som definerer alle tilgjengelige operasjoner.

REST-APIets styrker — simpelt, modent og bredt støttet

REST sin største fordel er enkelhet og modenhetsgrad. Alle utviklere forstår konseptet — det er intuitivt og ligner på web-arkitektur generelt. HTTP-caching virker naturlig med REST: en GET /products/42-respons kan caches av nettleseren, CDN-er og proxy-servere uten ekstra oppsett. Dette er en enorm ytelsesfordel for offentlige APIer.

REST er også enklere å sikre med standard HTTP-mekanismer. Rate limiting, autentisering og logging er enkelt å sette opp basert på URL og HTTP-metode. Verktøystøtten er enorm — Swagger/OpenAPI, Postman, Insomnia og nær sagt alle programmeringsspråk har utmerkede REST-biblioteker.

REST passer best for: enkle CRUD-applikasjoner, offentlige APIer der tredjepart skal integrere, systemer der HTTP-caching er kritisk for ytelse, og team uten GraphQL-erfaring.

GraphQL sine styrker — presisjon, fleksibilitet og bedre DX

GraphQLs største fordel er at klienten bestemmer nøyaktig hvilke felter den trenger. I REST returnerer /users/42 kanskje 30 felter — men mobilappen din trenger bare navn og profilbilde. Med GraphQL spør du bare om de feltene du trenger, noe som reduserer datamengden over nettverket dramatisk. Dette kalles at GraphQL eliminerer over-fetching.

Under-fetching er det motsatte problemet i REST: du må gjøre mange API-kall for å hente data du trenger. For å vise en brukers profil med bestillingshistorikk og leveringsadresser trenger du kanskje 4 REST-kall. Med GraphQL henter du alt i ett enkelt kall ved å komponere en nested query.

GraphQL sin sterk-typede schema gir automatisk dokumentasjon og gjør introspeksjon mulig — verktøy som GraphiQL lar deg utforske APIet interaktivt. TypeScript-generering fra schema gir full type-sikkerhet fra backend til frontend, noe som reduserer integrasjonsfeil dramatisk.

Side om side — REST vs. GraphQL

Direkte sammenligning av de viktigste dimensjonene:

N+1-problemet og GraphQL Dataloaders

GraphQL har et kjent ytelsesproblem kalt N+1-problemet. Hvis du spør om en liste med 100 brukere og deretter for-feltet country for hver bruker, kan serveren potensielt gjøre 101 databasekall (1 for listen + 100 for hvert lands-oppslag). Dette er en alvorlig ytelsesrisiko som ikke finnes på samme måte i REST der du kontrollerer alle SQL-spørringer.

Løsningen er DataLoader-biblioteket (opprinnelig fra Facebook). DataLoader samler alle country-oppslag i en enkelt batch-operasjon, slik at du fremdeles bare gjør 2 databasekall. Å implementere DataLoader riktig krever erfaring og disiplin. Dette er en av de praktiske kompleksitetene som gjør GraphQL vanskeligere å håndtere i produksjon enn REST.

"GraphQL løser problemer du har i store, komplekse applikasjoner. REST løser problemer du har i enkle, veldefinerte domener. Kjenn problemet ditt før du velger verktøy."

Konkret beslutningsguide — når bør du velge hva

Velg REST når: du bygger et offentlig API som tredjepart skal konsumere, caching er kritisk for ytelsen (f.eks. nyhetssider, e-handel), teamet er lite eller mangler GraphQL-erfaring, du jobber med enkle domener med tydelig ressurs-modell, eller du integrerer med systemer som forventer REST.

Velg GraphQL når: du har mange ulike klienter (mobil, nett, tredjepartsapper) med ulike databehov, du sliter med over- eller under-fetching i REST, du trenger realtime-funksjonalitet via subscriptions, applikasjonen har et komplekst og dypt nested datadomene (f.eks. sosiale nettverk, e-handel med mange relasjoner), eller du vil ha sterk typing fra ende til ende.

Et tredje alternativ er gRPC — Googles protokoll basert på Protocol Buffers. gRPC er raskere enn begge for intern kommunikasjon mellom mikrotjenester, men er ikke egnet for nettlesere uten ekstra lag. I 2025 bruker mange norske teknologiselskaper REST mot frontend, gRPC mellom backend-tjenester, og GraphQL som en federation-lag for komplekse produkter.