REST vs GraphQL vs gRPC — når ville du valgt hver av dem?

Question

IT Interview Practice · Accepted Answer

Dette er tre forskjellige API-paradigmer, hvert optimalisert for ulike begrensninger. Det finnes ingen universell vinner — det riktige valget avhenger av **konsumenten, dataformen og nettverket**.

## De tre i et øyekast

```text
           REST                 GraphQL              gRPC
Style      resources + HTTP     single query graph   RPC (call methods)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binary)
Fetching   fixed endpoints      client picks fields  fixed methods
Schema     optional (OpenAPI)   strong, typed        strong, .proto
Browser    native, cacheable    needs client lib     limited (needs proxy)
```

## REST

Ressursorientert over ren HTTP. **Velg det** for offentlige API-er, CRUD-tjenester, og alt som drar nytte av HTTP-caching, allestedsnærvær og enkelhet. Svakhetene er **over-fetching** (du får hele `/users/42` selv om du trenger ett felt) og **under-fetching** (`N+1`-problemet: hent en user, og loop deretter for å hente hver order).

```http
GET /users/42            → the whole user
GET /users/42/orders     → a second round trip
```

## GraphQL

Ett enkelt endepunkt der **klienten spesifiserer nøyaktig hva den vil ha** i én query, og løser over-/under-fetching. **Velg det** for rike frontender (spesielt mobil, der round trips er kostbare) og når mange klienter trenger ulike former av de samme dataene.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
Avveiinger: HTTP-caching er vanskeligere (alt er en `POST` til `/graphql`), og en naiv resolver kan skjule kostbare `N+1`-databasespørringer.

## gRPC

Kontrakt-først RPC som bruker **Protobuf** over **HTTP/2**. Binær og multiplekset, så den er rask og kompakt med streaming-støtte. **Velg det** for **intern service-til-service**-kommunikasjon i en mikrotjeneste-backend der ytelse og streng typing betyr noe. Svakhet: dårlig nettleserstøtte (trenger en proxy som grpc-web) og ikke menneskelesbar.

## Å velge

```text
Public API, CRUD, caching, wide reach   → REST
Complex/varied frontend data needs      → GraphQL
High-performance internal microservices → gRPC
(Real systems mix them: REST/GraphQL at the edge, gRPC between services.)
```

## Hvorfor det er viktig

På seniornivå bryr intervjuere seg mindre om definisjoner og mer om hvorvidt du kan **begrunne et valg mot begrensninger** — dette spørsmålet er egentlig "kan du matche en teknologi til et problem i stedet for å jage hype?" De sterkeste svarene forankres i smerten hver av dem løser: GraphQL finnes for å drepe over-/under-fetching for krevende frontender, gRPC finnes for å gjøre interne tjenestekall raske og sterkt typede, og REST forblir standarden fordi HTTP-caching, verktøy og universell fortrolighet er enorme praktiske fordeler for offentlige og CRUD-lignende API-er. Avgjørende: en senioringeniør bemerker at det **ikke er enten/eller** — en vanlig arkitektur er REST eller GraphQL på den offentlige kanten med gRPC mellom backend-mikrotjenester — og navngir de konkrete avveiingene (GraphQL sine caching- og `N+1`-risikoer, gRPC sin svake nettleserhistorie). Den resonneringen om passform og kostnad, ikke evnen til å ramse opp funksjoner, er signalet.

De tre i et øyekast

REST

GraphQL

gRPC

Å velge

Hvorfor det er viktig

Relaterte spørsmål