REST vs GraphQL vs gRPC — kdy byste zvolili který?

Question

IT Interview Practice · Accepted Answer

Tohle jsou tři různá API paradigmata, každé optimalizované pro jiná omezení. Neexistuje univerzální vítěz — správná volba závisí na **konzumentovi, tvaru dat a síti**.

## Tři na první pohled

```text
           REST                 GraphQL              gRPC
Styl       zdroje + HTTP        jeden query graf     RPC (volání metod)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binární)
Načítání   pevné endpointy      klient volí pole     pevné metody
Schema     volitelné (OpenAPI)  silné, typované      silné, .proto
Browser    nativní, cacheable   nutná klient. lib    omezené (nutná proxy)
```

## REST

Orientované na zdroje přes prosté HTTP. **Zvolte ho** pro veřejná API, CRUD služby a vše, co těží z HTTP cachování, všudypřítomnosti a jednoduchosti. Jeho slabinami jsou **over-fetching** (dostanete celého `/users/42`, i když potřebujete jedno pole) a **under-fetching** (problém `N+1`: načtěte uživatele, pak v cyklu načítejte každou objednávku).

```http
GET /users/42            → celý uživatel
GET /users/42/orders     → druhý round trip
```

## GraphQL

Jediný endpoint, kde **klient přesně specifikuje, co chce**, v jednom dotazu, což řeší over/under-fetching. **Zvolte ho** pro bohatá frontendová rozhraní (zejména mobilní, kde jsou round tripy nákladné) a když mnoho klientů potřebuje různé tvary týchž dat.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← jeden round trip, přesná pole
```
Kompromisy: HTTP cachování je těžší (vše je `POST` na `/graphql`) a naivní resolver může skrývat drahé databázové dotazy `N+1`.

## gRPC

RPC s kontraktem na prvním místě používající **Protobuf** přes **HTTP/2**. Binární a multiplexované, takže rychlé a kompaktní s podporou streamování. **Zvolte ho** pro **interní komunikaci service-to-service** v mikroslužbovém backendu, kde záleží na výkonu a striktním typování. Slabina: špatná podpora prohlížečů (potřebuje proxy jako grpc-web) a není čitelné pro člověka.

## Jak vybrat

```text
Veřejné API, CRUD, cachování, široký dosah → REST
Složité/různorodé potřeby dat frontendu    → GraphQL
Vysoce výkonné interní mikroslužby         → gRPC
(Reálné systémy je míchají: REST/GraphQL na okraji, gRPC mezi službami.)
```

## Proč je to důležité

Na seniorní úrovni tazatele méně zajímají definice a víc to, zda dokážete **obhájit volbu vůči omezením** — tato otázka je vlastně „umíte přiřadit technologii k problému místo honby za hype?“ Nejsilnější odpovědi se ukotví v bolesti, kterou každá řeší: GraphQL existuje, aby zabil over/under-fetching pro náročné frontendy, gRPC existuje, aby interní volání služeb byla rychlá a silně typovaná, a REST zůstává výchozí volbou, protože HTTP cachování, nástroje a univerzální znalost jsou obrovské praktické výhody pro veřejná a CRUD API. Zásadní je, že senior inženýr poznamená, že to **není buď-anebo** — běžná architektura je REST nebo GraphQL na veřejném okraji s gRPC mezi backendovými mikroslužbami — a jmenuje konkrétní kompromisy (rizika cachování a `N+1` u GraphQL, slabá podpora prohlížečů u gRPC). Právě toto uvažování o vhodnosti a ceně, ne schopnost odříkat vlastnosti, je oním signálem.

Tři na první pohled

REST

GraphQL

gRPC

Jak vybrat

Proč je to důležité

Související otázky