REST vs GraphQL vs gRPC — când ai alege fiecare?

Question

IT Interview Practice · Accepted Answer

Acestea sunt trei paradigme API diferite, fiecare optimizată pentru constrângeri diferite. Nu există un câștigător universal — alegerea potrivită depinde de **consumator, forma datelor și rețea**.

## Cele trei dintr-o privire

```text
           REST                 GraphQL              gRPC
Stil       resurse + HTTP       un singur query graph  RPC (apel de metode)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binar)
Fetching   endpoint-uri fixe    clientul alege câmpuri  metode fixe
Schema     opțional (OpenAPI)   puternic, tipizat    puternic, .proto
Browser    nativ, cacheable     necesită client lib  limitat (necesită proxy)
```

## REST

Orientat pe resurse peste HTTP simplu. **Alege-l** pentru API-uri publice, servicii CRUD și orice beneficiază de HTTP caching, ubicuitate și simplitate. Slăbiciunile sale sunt **over-fetching** (primești tot `/users/42` chiar dacă ai nevoie de un câmp) și **under-fetching** (problema `N+1`: preia un utilizator, apoi buclează pentru a prelua fiecare comandă).

```http
GET /users/42            → tot user-ul
GET /users/42/orders     → un al doilea round trip
```

## GraphQL

Un singur endpoint unde **clientul specifică exact ce vrea** într-o singură interogare, rezolvând over/under-fetching. **Alege-l** pentru frontend-uri bogate (mai ales mobile, unde round trip-urile sunt costisitoare) și când mulți clienți au nevoie de forme diferite ale acelorași date.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← un singur round trip, exact câmpurile
```
Compromisuri: HTTP caching-ul este mai greu (totul este un `POST` către `/graphql`), iar un resolver naiv poate ascunde interogări de bază de date `N+1` costisitoare.

## gRPC

RPC contract-first folosind **Protobuf** peste **HTTP/2**. Binar și multiplexat, deci este rapid și compact, cu suport pentru streaming. **Alege-l** pentru comunicarea **internă service-to-service** într-un backend de microservicii unde performanța și tiparea strictă contează. Slăbiciune: suport slab în browser (necesită un proxy precum grpc-web) și necitibil de om.

## Cum alegi

```text
API public, CRUD, caching, acoperire largă   → REST
Nevoi complexe/variate de date pe frontend    → GraphQL
Microservicii interne de înaltă performanță   → gRPC
(Sistemele reale le combină: REST/GraphQL la margine, gRPC între servicii.)
```

## De ce contează

La nivel senior, intervievatorilor le pasă mai puțin de definiții și mai mult dacă poți **justifica o alegere în raport cu constrângerile** — această întrebare este de fapt „poți potrivi o tehnologie cu o problemă în loc să alergi după hype?". Cele mai bune răspunsuri se ancorează pe durerea pe care o rezolvă fiecare: GraphQL există pentru a elimina over/under-fetching pentru frontend-uri exigente, gRPC există pentru a face apelurile interne de servicii rapide și puternic tipizate, iar REST rămâne implicitul pentru că HTTP caching, tooling-ul și familiaritatea universală sunt avantaje practice enorme pentru API-uri publice și de tip CRUD. Crucial, un inginer senior notează că **nu este sau/sau** — o arhitectură comună este REST sau GraphQL la marginea publică cu gRPC între microserviciile backend — și numește compromisurile concrete (riscurile de caching și `N+1` ale GraphQL, povestea slabă în browser a gRPC). Acel raționament despre potrivire și cost, nu abilitatea de a recita funcționalități, este semnalul.

Cele trei dintr-o privire

REST

GraphQL

gRPC

Cum alegi

De ce contează

Întrebări conexe