REST vs GraphQL vs gRPC — när skulle du välja var och en?

Question

IT Interview Practice · Accepted Answer

Dessa är tre olika API-paradigm, var och en optimerad för olika constraints. Det finns ingen universell vinnare — rätt val beror på **konsumenten, dataformen och nätverket**.

## De tre i korthet

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

Resursorienterad över vanlig HTTP. **Välj det** för publika API:er, CRUD-tjänster, och allt som gynnas av HTTP-caching, allestädesnärvaro och enkelhet. Dess svagheter är **over-fetching** (du får hela `/users/42` även om du behöver ett fält) och **under-fetching** (`N+1`-problemet: hämta en user, loopa sedan för att hämta varje order).

```http
GET /users/42            → hela user:n
GET /users/42/orders     → en andra round trip
```

## GraphQL

En enda endpoint där **client:en anger exakt vad den vill ha** i en query, vilket löser over/under-fetching. **Välj det** för rika frontends (särskilt mobil, där round trips är kostsamma) och när många clients behöver olika former av samma data.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← en round trip, exakta fält
```
Avvägningar: HTTP-caching är svårare (allt är en `POST` till `/graphql`), och en naiv resolver kan dölja dyra `N+1`-databasfrågor.

## gRPC

Contract-first RPC med **Protobuf** över **HTTP/2**. Binär och multiplexad, så den är snabb och kompakt med streaming-stöd. **Välj det** för **intern service-to-service**-kommunikation i en microservices-backend där prestanda och strikt typning spelar roll. Svaghet: dåligt browser-stöd (behöver en proxy som grpc-web) och inte människoläsbar.

## Att välja

```text
Publikt API, CRUD, caching, bred räckvidd  → REST
Komplexa/varierade frontend-databehov      → GraphQL
Högpresterande interna microservices       → gRPC
(Verkliga system mixar dem: REST/GraphQL i kanten, gRPC mellan tjänster.)
```

## Varför det är viktigt

På seniornivå bryr sig intervjuare mindre om definitioner och mer om huruvida du kan **motivera ett val mot constraints** — denna fråga är egentligen "kan du matcha en teknik mot ett problem i stället för att jaga hype?" De starkaste svaren förankras i smärtan var och en löser: GraphQL existerar för att döda over/under-fetching för krävande frontends, gRPC existerar för att göra interna service-anrop snabba och starkt typade, och REST förblir standardvalet eftersom HTTP-caching, verktyg och universell förtrogenhet är enorma praktiska fördelar för publika och CRUD-liknande API:er. Avgörande är att en senior ingenjör noterar att det **inte är antingen/eller** — en vanlig arkitektur är REST eller GraphQL i den publika kanten med gRPC mellan backend-microservices — och namnger de konkreta avvägningarna (GraphQL:s caching- och `N+1`-risker, gRPC:s svaga browser-story). Det resonemanget om lämplighet och kostnad, inte förmågan att rabbla funktioner, är signalen.

De tre i korthet

REST

GraphQL

gRPC

Att välja

Varför det är viktigt

Relaterade frågor