REST vs gRPC vs GraphQL: API İletişim Protokolleri Karşılaştırması

Backend servisleri arasında ya da istemci ile backend arasında veri alışverişi yapmanın birden fazla yolu vardır. En popüler üçü: REST, gRPC ve GraphQL. Hangisi en iyisi? Cevap: "Duruma bağlı."

REST (Representational State Transfer)

REST, HTTP üzerinden kaynak tabanlı (resource-based) iletişim sağlar. 2000'li yıllardan beri web'in standart API yaklaşımıdır.

Nasıl Çalışır?

GET    /api/users          → Tüm kullanıcıları listele
GET    /api/users/42       → ID=42 kullanıcıyı getir
POST   /api/users          → Yeni kullanıcı oluştur
PUT    /api/users/42       → Kullanıcıyı güncelle
DELETE /api/users/42       → Kullanıcıyı sil

Avantajlar

• Basit ve yaygın
• HTTP standartlarına uygun
• Cache mekanizması dahili
• Tüm dil ve platformlar destekler

Dezavantajlar

• Over-fetching: İhtiyacından fazla veri çekme
• Under-fetching: Birden fazla istek gerekebilir
• Versiyon yönetimi karmaşıklaşabilir

gRPC (Google Remote Procedure Call)

Google tarafından geliştirilen, Protocol Buffers (protobuf) tabanlı yüksek performanslı RPC framework'ü.

Nasıl Çalışır?

// user.proto
service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
  rpc ListUsers (Empty) returns (stream UserResponse);
}

message UserRequest {
  int32 id = 1;
}

message UserResponse {
  int32 id = 1;
  string name = 2;
  string email = 3;
}

Avantajlar

• Çok yüksek performans — Binary serialization
• HTTP/2 üzerinde çalışır (multiplexing, streaming)
• Tip güvenliği (strongly typed)
• Bi-directional streaming desteği
• Otomatik kod üretimi (code generation)

Dezavantajlar

• Tarayıcı desteği sınırlı
• Debugging zor (binary format)
• Öğrenme eğrisi daha yüksek

GraphQL

Facebook tarafından geliştirilen, istemcinin ihtiyaç duyduğu veriyi tam olarak isteyebildiği sorgu dili.

Nasıl Çalışır?

# İstemci tam olarak istediği alanları belirtir
query {
  user(id: 42) {
    name
    email
    posts(limit: 5) {
      title
      createdAt
    }
  }
}

Avantajlar

• Tam veri kontrolü — Over/under-fetching yok
• Tek endpoint (/graphql)
• Güçlü tip sistemi ve introspection
• İlişkisel veriler için ideal

Dezavantajlar

• Caching karmaşık (POST istekleri)
• N+1 sorgu problemi
• Dosya upload/download karmaşık
• Basit CRUD için fazla karmaşık

Karşılaştırma Tablosu

| Özellik | REST | gRPC | GraphQL | |---------|------|------|---------| | Protokol | HTTP/1.1 | HTTP/2 | HTTP/1.1 | | Veri formatı | JSON | Protobuf (binary) | JSON | | Performans | Orta | Çok yüksek | Orta | | Öğrenme eğrisi | Düşük | Yüksek | Orta | | Tarayıcı desteği | ✅ Tam | ⚠️ Sınırlı | ✅ Tam | | Streaming | ❌ | ✅ | ⚠️ Subscription | | Caching | ✅ Kolay | ❌ Zor | ⚠️ Karmaşık | | Tip güvenliği | ❌ | ✅ | ✅ | | Dosya transfer | ✅ Kolay | ⚠️ | ⚠️ |

Hangisini Ne Zaman Kullanmalı?

REST Kullanın

• Public API'ler
• Basit CRUD operasyonları
• Caching önemli
• Geniş ekosistem gerekli

gRPC Kullanın

• Mikroservisler arası iletişim
• Yüksek performans gerekli
• Real-time streaming
• Dahili servis iletişimi

GraphQL Kullanın

• Karmaşık ilişkisel veriler
• Mobil uygulamalar (bant genişliği tasarrufu)
• Farklı istemciler farklı veri istiyor
• Hızlı prototipleme

Hybrid Yaklaşım

Gerçek dünyada çoğu zaman birden fazla protokol birlikte kullanılır:

İstemci (Web/Mobil) ←→ GraphQL/REST ←→ API Gateway
                                            ↓
Servis A ←→ gRPC ←→ Servis B
Servis C ←→ gRPC ←→ Servis D

Sonuç

Tek bir "en iyi" protokol yoktur. REST, basitlik ve yaygınlık istiyorsanız; gRPC, performance-critical servisler arası iletişim için; GraphQL ise karmaşık frontend ihtiyaçları için idealdir.

API tasarımı ve mikroservis iletişim kalıplarını Yazılım Mimarisi 3.0 kitabında derinlemesine inceliyoruz.