Giriş
Yıl 2025. Hâlâ REST API geliştiriyor ve mevcut sistemlerdeki eski servisleri buna dönüştürüyoruz. Ama bu, doğru seçim yaptığımız anlamına gelmiyor olabilir. Web API mimarileri son 10 yılda radikal bir değişim geçirdi. REST hâlâ hayatta, evet. Ama artık ölçeklenebilirlik, esneklik, güvenlik, hız ve geliştirici deneyimi açısından ihtiyaçlarımız değişti.
Bu yazıda:
- REST, GraphQL ve gRPC mimarilerinin güçlü/zayıf yönlerini kıyaslayacağız,
- API altyapısını taşıyan temel yapıtaşlarını inceleyeceğiz: API Gateway, OAuth2, Rate Limiting, Gözlemleme.
Amaç: Mimariden önce senaryoyu anlamak, doğru API yaklaşımını doğru sistemlerde kullanmak.
1. REST API – Hâlâ Varsayılan, Ama Neden?
Ne İşe Yarar?
REST (Representational State Transfer), HTTP protokolü üzerinde çalışan, URI tabanlı kaynak erişimi sağlayan ve JSON ile iletişim kuran sistemlerin omurgasını oluşturur.
Avantajları
- CRUD operasyonları için idealdir
- Her frontend kolaylıkla entegre olur
- HTTP’ye tam uyumludur (GET, POST, PUT, DELETE)
Dezavantajları
- Overfetching/Underfetching: Gereksiz veri taşınabilir
- Versionlama karmaşası: /v1/users, /v2/users gibi URI çözümleri
- Veri esnekliği sınırlı: Sabit endpoint yapıları
Ne Zaman Kullanılır?
- Basit CRUD uygulamaları
- Mobil API’ler
- Tek sorumluluğu olan mikroservisler
2. GraphQL – Kontrolü İstemciye Veren Güçlü Ama Zorlayıcı Yapı
Ne İşe Yarar?
İstemcinin yalnızca ihtiyacı olan veriyi sorgulayabildiği, tip güvenli ve tek endpoint ile çalışan bir sorgu dili sunar.
Avantajları
- Overfetching yok, sadece ihtiyaç olan veri alınır
- Frontend, veri yapısını belirleyebilir
- Otomatik şema dokümantasyonu (Playground, Voyager)
Dezavantajları
- Sunucu tarafında caching zordur
- Field-level authorization karmaşıklaşır
- Resolver mimarisi kötü tasarlanırsa N+1 sorgu problemi yaşanabilir
- HTTP status kodlarının yeri yerine response içinde hata objesi gelir
Ne Zaman Kullanılır?
- Modern frontend mimarilerinde
- Mobilde veri trafiğini azaltmak gerektiğinde
- Büyük veri modellerinde esneklik gerekiyorsa
3. gRPC – Mikroservislerin Sessiz Kahramanı
Ne İşe Yarar?
gRPC, Google tarafından geliştirilen, Protobuf formatında veri taşıyan, HTTP/2 tabanlı bir RPC protokolüdür. Özellikle mikroservis mimarilerinde servisler arası hızlı ve düşük gecikmeli iletişim için biçilmiş kaftandır.
Avantajları
- Performans yüksek, payload küçük. Protobuf metin değil, binarydir.
- Streaming desteği var. Hem client-to-server hem de bidirectional streaming mümkün.
- Dil bağımsızlığı: C#, Go, Java, Rust… Hepsiyle uyumlu.
Dezavantajları
- Web tarayıcılar doğrudan desteklemez. Bu nedenle gRPC-Web gibi proxy çözümler gerekir.
- Debugging zordur. JSON değil, okunabilirlik yok.
- Öğrenme eğrisi dik. REST kadar yaygın değil, alışkanlıklar farklı.
Ne Zaman Kullanılır?
- Mikroservis-to-mikroservis iletişiminde
- Gerçek zamanlı veri akışında (streaming)
- Performansın kritik olduğu sistemlerde
4. API Altyapısı Nasıl Sağlam Kurulur?
4.1 API Gateway: Modern Servis Mimarilerinin Omurgası
Ne İşe Yarar?
- Routing (istek yönlendirme)
- Authentication & Authorization (JWT, API Key, OAuth2)
- Rate Limiting
- Response Caching
- Loglama ve monitoring entegrasyonu
- SSL Termination ve CORS yönetimi
- Request/Response transformasyonu ve aggregasyonu
Popüler Gateway Çözümleri
| Ürün | Açık Kaynak | Cloud Uyumlu | Eklenti Sistemi | Geliştirici Desteği |
| Kong | ✅ | ✅ | Lua tabanlı güçlü | Çok aktif |
| Tyk | ✅ | ✅ | JS middleware | Orta düzey |
| AWS API Gateway | ❌ | ✅ | Native AWS | Yüksek |
| Azure API Mgmt | ❌ | ✅ | Azure Function entegrasyonu | Yüksek |
| Traefik Gateway | ✅ | ✅ | Plugin’li | Go tabanlı çevik |
Ne Zaman Gerekli?
- Mikroservis sayınız ikiyi geçtiyse
- Farklı istemci tipleri varsa (web, mobil, IoT)
- SSO, OAuth2 gibi entegrasyonlar düşünülüyorsa
- Rate limiting ya da SLA gibi servis kalitesi ihtiyacı varsa
Gateway koymadan geliştirilen sistemler kısa vadede hızlı başlasa da orta vadede güvenlik, loglama, erişim kontrolü ve versiyonlama konularında içinden çıkılamaz hale gelir.
4.2 OAuth2 ve Token Yönetimi: Kimlik Doğrulamanın Omurgası
Ne İşe Yarar?
Kullanıcının şifresini ifşa etmeden sistem üzerinde güvenli işlem yapmasına izin verir. Genellikle JWT ile birlikte çalışır.
Senaryolar
- Mobil uygulama API’ye erişmek istiyor ama şifre bilgisi paylaşılmaz
- 3. parti bir servis, kullanıcı adına işlem yapacak
- Kullanıcıyı frontend’de login ettin, backend’de doğrulamak istiyorsun
Token Türleri
- Access Token: Kısa ömürlü, işlem yetkisi sağlar
- Refresh Token: Yeni access token almak için kullanılır
Refresh Token Akışı
- Kullanıcı login olur, access + refresh token alır
- Access token süresi biter
- Refresh token ile yeni access token alınır
- Refresh token süresi de biterse → yeniden login gerekir
Güvenlik Notları
- Access token kısa süreli tutulmalı
- Refresh token client tarafında secure storage (mobilde) veya HttpOnly + Secure cookie ile saklanmalı
- JWT imzalanmalı (RS256 önerilir)
- Token iptal listesi (revocation) gerekir. JWT tek başına merkezi iptal sunmaz.
Sık Yapılan Hatalar
| Hata | Açıklama |
| Access token’a 1 hafta ömür vermek | Token çalınırsa sistem 1 hafta boyunca açıktır |
| Refresh token’ı localStorage’da tutmak | Tarayıcıdan erişilebilir, XSS ile çalınabilir |
| JWT içeriğini fazla doldurmak | Payload büyür, ağ trafiği artar, saklama zorlaşır |
4.3 Gözlemleme ve Loglama: Ölçemediğini Yönetemezsin
Neden Gereklidir?
- Performans düşüşlerini anlamak
- Root cause analizi yapmak
- Gerçek kullanıcı deneyimini takip etmek
Bileşenler
- OpenTelemetry: Logs, Metrics, Traces toplar
- Jaeger: Dağıtık izleme ve trace analizi sağlar
- Prometheus: Zaman serisi veri toplar
- Grafana: Metric’leri görselleştirir
Loglanacak Veri Türleri
| Tür | Açıklama |
| Log | İş akışı, hata, uyarılar (Structured JSON) |
| Metric | CPU, bellek, istek süresi, hata oranı |
| Trace | Servisler arası çağrı zinciri |
Entegrasyon Akışı
Kod → OpenTelemetry Agent →
→ Jaeger (trace) + Prometheus (metric) →
→ Grafana (dashboard)
“Log yoksa hata yok” devri kapandı. Artık “log varsa anlam var” devri başladı.
Sonuç: Doğru Araç, Doğru Problem için
Hiçbir mimari diğerini tamamen ortadan kaldırmadı. REST hâlâ varsayılan. GraphQL bazı alanlarda nefes aldırıyor. gRPC ise sistem içi iletişimin yeni standardı olmaya aday.
Sistem tasarlarken sorulması gereken asıl sorular şunlar:
- API yalnızca veri mi sunacak, yoksa davranış da mı taşıyacak?
- Hedef istemciler kimler? (web, mobil, servis)
- Takım bu teknolojiyi sürdürebilir mi?
- Gözlemleme, güvenlik, ölçeklenebilirlik için ne kadar yatırım yapılacak?
“Login olduktan sonra her şey bitmiyor. Asıl oyun, mimariyi yaşatmakla başlıyor.”
