REST vs. GraphQL vs. gRPC — wann würdest du welches wählen?

Question

IT Interview Practice · Accepted Answer

Das sind drei verschiedene API-Paradigmen, jedes für andere Constraints optimiert. Es gibt keinen universellen Gewinner — die richtige Wahl hängt vom **Konsumenten, der Datenform und dem Netzwerk** ab.

## Die drei auf einen Blick

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

Ressourcenorientiert über einfaches HTTP. **Wähle es** für öffentliche APIs, CRUD-Dienste und alles, was von HTTP-Caching, Allgegenwart und Einfachheit profitiert. Seine Schwächen sind **Over-Fetching** (du bekommst den ganzen `/users/42`, auch wenn du ein Feld brauchst) und **Under-Fetching** (das `N+1`-Problem: einen User holen, dann in einer Schleife jede Order holen).

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

## GraphQL

Ein einzelner Endpoint, an dem der **Client in einer Query genau angibt, was er will**, was Over-/Under-Fetching löst. **Wähle es** für reichhaltige Frontends (besonders Mobile, wo Round Trips teuer sind) und wenn viele Clients unterschiedliche Formen derselben Daten brauchen.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
Trade-offs: HTTP-Caching ist schwerer (alles ist ein `POST` an `/graphql`), und ein naiver Resolver kann teure `N+1`-Datenbankabfragen verbergen.

## gRPC

Contract-First-RPC mit **Protobuf** über **HTTP/2**. Binär und multiplext, daher schnell und kompakt mit Streaming-Unterstützung. **Wähle es** für **interne Service-zu-Service**-Kommunikation in einem Microservices-Backend, wo Performance und strikte Typisierung zählen. Schwäche: schlechte Browser-Unterstützung (braucht einen Proxy wie grpc-web) und nicht menschenlesbar.

## Wählen

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

## Warum es wichtig ist

Auf Senior-Niveau interessieren sich Interviewer weniger für Definitionen und mehr dafür, ob du **eine Wahl gegen Constraints begründen** kannst — diese Frage lautet eigentlich "kannst du eine Technologie an ein Problem anpassen, statt dem Hype nachzujagen?". Die stärksten Antworten verankern sich im Schmerz, den jedes löst: GraphQL existiert, um Over-/Under-Fetching für anspruchsvolle Frontends zu beseitigen, gRPC existiert, um interne Service-Calls schnell und stark typisiert zu machen, und REST bleibt der Standard, weil HTTP-Caching, Tooling und universelle Vertrautheit enorme praktische Vorteile für öffentliche und CRUD-artige APIs sind. Entscheidend merkt ein Senior-Ingenieur an, dass es **nicht Entweder-oder** ist — eine verbreitete Architektur ist REST oder GraphQL am öffentlichen Rand mit gRPC zwischen Backend-Microservices — und benennt die konkreten Trade-offs (GraphQLs Caching- und `N+1`-Risiken, gRPCs schwache Browser-Story). Dieses Denken über Passung und Kosten, nicht die Fähigkeit, Features aufzusagen, ist das Signal.

Die drei auf einen Blick

REST

GraphQL

gRPC

Wählen

Warum es wichtig ist

Ähnliche Fragen