REST vs GraphQL vs gRPC — her birini ne zaman seçersiniz?

Question

IT Interview Practice · Accepted Answer

Bunlar üç farklı API paradigmasıdır, her biri farklı kısıtlar için optimize edilmiştir. Evrensel bir kazanan yoktur — doğru seçim **tüketiciye, veri biçimine ve ağa** bağlıdır.

## Üçüne bir bakış

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

Düz HTTP üzerinde resource odaklı. Public API'ler, CRUD servisleri ve HTTP caching, yaygınlık ve basitlikten faydalanan her şey için **onu seçin**. Zayıflıkları **over-fetching** (bir alana ihtiyacınız olsa bile tüm `/users/42`'yi alırsınız) ve **under-fetching** (`N+1` sorunu: bir user getir, sonra her order'ı getirmek için döngüye gir).

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

## GraphQL

**Client'ın tam olarak ne istediğini** tek bir sorguda belirttiği tek bir endpoint; over/under-fetching'i çözer. Zengin frontend'ler için (özellikle round trip'lerin maliyetli olduğu mobile) ve birçok client'ın aynı verinin farklı biçimlerine ihtiyaç duyduğu durumlarda **onu seçin**.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
Ödünleşimler: HTTP caching daha zordur (her şey `/graphql`'e bir `POST`'tur) ve naif bir resolver, pahalı `N+1` veritabanı sorgularını gizleyebilir.

## gRPC

**HTTP/2** üzerinden **Protobuf** kullanan, sözleşme öncelikli (contract-first) RPC. İkili (binary) ve çoğullanmış (multiplexed), bu yüzden streaming desteğiyle hızlı ve kompakttır. Performansın ve katı tiplemenin önemli olduğu bir microservices backend'inde **iç service-to-service** iletişim için **onu seçin**. Zayıflık: zayıf browser desteği (grpc-web gibi bir proxy gerektirir) ve insan tarafından okunamaması.

## Seçim

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

## Neden önemli

Senior düzeyde mülakatçılar tanımlardan çok, bir **seçimi kısıtlara karşı gerekçelendirip** gerekçelendiremediğinizle ilgilenir — bu soru aslında "hype'ın peşinden koşmak yerine bir teknolojiyi bir soruna eşleyebiliyor musun?" demektir. En güçlü cevaplar her birinin çözdüğü acıya demir atar: GraphQL, talepkâr frontend'ler için over/under-fetching'i öldürmek için vardır, gRPC iç service çağrılarını hızlı ve katı tipli yapmak için vardır ve REST, HTTP caching, araçlar ve evrensel aşinalık public ile CRUD tarzı API'ler için muazzam pratik avantajlar olduğundan varsayılan olmaya devam eder. Kritik olarak, bir senior mühendis bunun **ya o ya bu olmadığını** belirtir — yaygın bir mimari, public kenarda REST ya da GraphQL, backend microservice'ler arasında gRPC'dir — ve somut ödünleşimleri adlandırır (GraphQL'in caching ve `N+1` riskleri, gRPC'nin zayıf browser hikâyesi). Sinyal, özellikleri ezbere okuma yeteneği değil, uygunluk ve maliyet üzerine o akıl yürütmedir.

Üçüne bir bakış

REST

GraphQL

gRPC

Seçim

Neden önemli

İlgili sorular