REST vs GraphQL — hva bør du velge for ditt API?

Hva er REST og hvorfor er det standarden?

REST — Representational State Transfer — er en arkitekturstil for å designe nettverksapplikasjoner. Det hviler på HTTP-protokollen og bruker URL-er til å representere ressurser og HTTP-metoder til å definere operasjoner: GET for å lese, POST for å opprette, PUT/PATCH for å oppdatere og DELETE for å slette. Et REST API for en norsk nettbutikk kan ha endepunkter som `GET /produkter`, `GET /produkter/123`, `POST /bestillinger` og `DELETE /bestillinger/456`.

REST er standarden fordi det er enkelt, intuitivt, utnytter HTTP fullt ut (caching, autentisering, statuskoder), og har eksistert lenge nok til at alle verktøy, biblioteker og utviklere forstår det. For et enkelt CRUD-API er REST nesten alltid det riktige valget.

GraphQL — fleksibilitet på bekostning av kompleksitet

GraphQL er et spørrespråk for API-er der klienten spesifiserer nøyaktig hvilke data den vil ha. Istedenfor mange endepunkter har du ett: `/graphql`. Klienten sender en query-tekst som beskriver ønsket datastruktur, og serveren returnerer nøyaktig den strukturen — ikke mer, ikke mindre.

Tenk på det slik: med REST kaller du `GET /brukere/123` og får tilbake et JSON-objekt med alle brukerens feltene — kanskje 20 felt — selv om du bare trengte navn og epost. Med GraphQL sender du en query: `{ bruker(id: 123) { navn epost } }` og får bare navn og epost tilbake. Dette er GraphQL i nøtteskall.

Over-fetching, under-fetching og N+1-problemet

Over-fetching betyr at API-et returnerer mer data enn klienten trenger. Under-fetching betyr at du må kalle flere endepunkter for å samle dataen du trenger — for eksempel `GET /innlegg` fulgt av `GET /brukere/1`, `GET /brukere/2` osv. for hvert innlegg. Dette siste er N+1-problemet: én forespørsel genererer N ytterligere forespørsler. GraphQL løser over- og underfetching elegant, men introduserer sitt eget N+1-problem på serversiden. Løsningen er DataLoader-mønsteret som batcher og memoizerer database-oppslag.

Når passer GraphQL — og når bør du la være?

GraphQL passer best når du har mange forskjellige klienter med ulike databehov: en mobilapp trenger færre felt enn en webapp, og en tredjeparts integrasjon trenger en helt annen datastruktur. GitHub brukte nettopp dette som begrunnelse da de lanserte sin GraphQL API v4 — tusenvis av kunder med radikalt ulike behov. Shopify bruker GraphQL til sin Storefront API fordi nettbutikker har svært varierende behov.

GraphQL bør du derimot unngå for enkle CRUD-API-er, for team uten GraphQL-erfaring (læringskurven er bratt), og for API-er der caching er kritisk (REST + CDN er mye enklere). For et norsk startup med 2 utviklere og ett enkelt web-grensesnitt er GraphQL overdrevent. For et norsk selskap med iOS-app, Android-app, webapp og offentlig API er det verdt å vurdere.

tRPC — det moderne alternativet for TypeScript-prosjekter

tRPC er ikke et API-protokoll i tradisjonell forstand — det er et bibliotek for å lage typesikre API-er i fullstack TypeScript-prosjekter (Next.js, SvelteKit). Med tRPC definerer du server-side "procedures" (queries og mutations), og klienten kaller dem med full TypeScript-typeinferens — uten å generere noen kode, uten schemas og uten kodegenerering.

Et eksempel: du definerer `getUserById(id: number): Promise<User>` på serveren. Klienten kaller `trpc.getUserById.query({ id: 123 })` og TypeScript vet nøyaktig hva som returneres. Hvis du endrer returtypen på serveren, klager klienten umiddelbart. For norske startups som bruker Next.js og TypeScript er tRPC i 2025 et svært populært alternativ som eliminerer behovet for både REST-dokumentasjon og GraphQL-kompleksitet.

Konklusjon — velg etter behov, ikke hype

REST er fremdeles riktig valg for de fleste API-er. Det er universelt forstått, enkelt å dokumentere (Swagger/OpenAPI), enkelt å cache og har den laveste inngangsbarrieren. Bruk REST som standard, og vurder alternativer kun når du har konkrete smertepunkter REST ikke løser.

GraphQL er det riktige valget om du har multiple klienter med vidt forskjellige databehov, og har kapasitet til å håndtere den ekstra kompleksiteten. tRPC er det beste valget for fullstack TypeScript-applikasjoner i Next.js eller SvelteKit der du kontrollerer både frontend og backend. Det er ingen universell vinner — kontekst er alt.