REST vs. GraphQL vs. gRPC — milloin valitsisit minkäkin?

Question

IT Interview Practice · Accepted Answer

Nämä ovat kolme eri API-paradigmaa, kukin optimoitu eri rajoitteille. Universaalia voittajaa ei ole — oikea valinta riippuu **kuluttajasta, datan muodosta ja verkosta**.

## Kolme yhdellä silmäyksellä

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

Resurssikeskeinen tavallisen HTTP:n yli. **Valitse se** julkisille API:eille, CRUD-palveluille ja kaikelle, joka hyötyy HTTP-cachetuksesta, kaikkiallisuudesta ja yksinkertaisuudesta. Sen heikkoudet ovat **over-fetching** (saat koko `/users/42`:n vaikka tarvitsisit yhden kentän) ja **under-fetching** (`N+1`-ongelma: hae käyttäjä, sitten silmukoi hakeaksesi jokaisen tilauksen).

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

## GraphQL

Yksi endpoint, jossa **client määrittää tarkalleen mitä haluaa** yhdessä kyselyssä, ratkaisten over/under-fetchingin. **Valitse se** rikkaille frontendeille (erityisesti mobiilille, jossa round tripit ovat kalliita) ja kun monet clientit tarvitsevat saman datan eri muotoja.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
Kompromissit: HTTP-cachetus on vaikeampaa (kaikki on `POST` osoitteeseen `/graphql`), ja naiivi resolver voi piilottaa kalliita `N+1`-tietokantakyselyjä.

## gRPC

Sopimuslähtöinen RPC käyttäen **Protobufia** **HTTP/2**:n yli. Binäärinen ja multipleksattu, joten se on nopea ja tiivis streaming-tuella. **Valitse se** **sisäiseen service-to-service** -kommunikaatioon mikropalvelu-backendissä, jossa suorituskyky ja tiukka tyypitys ovat tärkeitä. Heikkous: huono selaintuki (tarvitsee proxyn kuten grpc-web) eikä ihmisluettava.

## Valitseminen

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

## Miksi se on tärkeää

Senior-tasolla haastattelijat välittävät vähemmän määritelmistä ja enemmän siitä, osaatko **perustella valinnan rajoitteita vastaan** — tämä kysymys on todellisuudessa "osaatko sovittaa teknologian ongelmaan hypen tavoittelun sijaan?" Vahvimmat vastaukset ankkuroituvat kunkin ratkaisemaan kipuun: GraphQL on olemassa tappamaan over/under-fetchingin vaativille frontendeille, gRPC on olemassa tekemään sisäisistä service-kutsuista nopeita ja vahvasti tyypitettyjä, ja REST pysyy oletuksena, koska HTTP-cachetus, työkalutus ja universaali tuttuus ovat valtavia käytännön etuja julkisille ja CRUD-tyylisille API:eille. Ratkaisevasti senior-insinööri huomauttaa, ettei se ole **joko-tai** — yleinen arkkitehtuuri on REST tai GraphQL julkisessa reunassa gRPC:n ollessa backend-mikropalvelujen välillä — ja nimeää konkreettiset kompromissit (GraphQL:n cachetus- ja `N+1`-riskit, gRPC:n heikko selaintarina). Juuri tuo päättely sopivuudesta ja kustannuksesta, ei kyky luetella ominaisuuksia, on signaali.

Kolme yhdellä silmäyksellä

REST

GraphQL

gRPC

Valitseminen

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset