REST vs. GraphQL vs. gRPC — hvornår ville du vælge hver af dem?

Question

IT Interview Practice · Accepted Answer

Dette er tre forskellige API-paradigmer, hver optimeret til forskellige constraints. Der er ingen universel vinder — det rigtige valg afhænger af **forbrugeren, dataformen og netværket**.

## De tre i et overblik

```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

Resource-orienteret over almindelig HTTP. **Vælg den** til offentlige APIs, CRUD-tjenester og alt, der drager fordel af HTTP-caching, allestedsnærvær og enkelhed. Dens svagheder er **over-fetching** (du får hele `/users/42`, selvom du kun har brug for ét felt) og **under-fetching** (`N+1`-problemet: hent en user, og loop så for at hente hver ordre).

```http
GET /users/42            → hele useren
GET /users/42/orders     → endnu et round trip
```

## GraphQL

Et enkelt endpoint, hvor **clienten specificerer præcis, hvad den vil have**, i én query, hvilket løser over-/under-fetching. **Vælg den** til rige frontends (især mobil, hvor round trips er dyre) og når mange clients har brug for forskellige former af de samme data.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← ét round trip, præcise felter
```
Afvejninger: HTTP-caching er sværere (alt er en `POST` til `/graphql`), og en naiv resolver kan skjule dyre `N+1`-databaseforespørgsler.

## gRPC

Contract-first RPC, der bruger **Protobuf** over **HTTP/2**. Binær og multiplexet, så den er hurtig og kompakt med streaming-understøttelse. **Vælg den** til **intern service-to-service**-kommunikation i en microservices-backend, hvor performance og streng typning betyder noget. Svaghed: dårlig browser-understøttelse (kræver en proxy som grpc-web) og ikke menneskelæsbar.

## At vælge

```text
Offentlig API, CRUD, caching, bred rækkevidde → REST
Komplekse/varierede frontend-databehov        → GraphQL
Højtydende interne microservices              → gRPC
(Rigtige systemer blander dem: REST/GraphQL ved kanten, gRPC mellem services.)
```

## Hvorfor det betyder noget

På seniorniveau bekymrer interviewere sig mindre om definitioner og mere om, hvorvidt du kan **begrunde et valg over for constraints** — dette spørgsmål er i virkeligheden "kan du matche en teknologi til et problem i stedet for at jagte hype?". De stærkeste svar forankrer sig i den smerte, hver af dem løser: GraphQL findes for at dræbe over-/under-fetching for krævende frontends, gRPC findes for at gøre interne service-kald hurtige og stærkt typede, og REST forbliver standarden, fordi HTTP-caching, tooling og universel fortrolighed er enorme praktiske fordele for offentlige og CRUD-agtige APIs. Afgørende bemærker en senioringeniør, at det **ikke er enten-eller** — en almindelig arkitektur er REST eller GraphQL ved den offentlige kant med gRPC mellem backend-microservices — og navngiver de konkrete afvejninger (GraphQL's caching- og `N+1`-risici, gRPC's svage browser-historie). Netop det ræsonnement om egnethed og omkostning, ikke evnen til at fremsige features, er signalet.

De tre i et overblik

REST

GraphQL

gRPC

At vælge

Hvorfor det betyder noget

Relaterede spørgsmål