Mobil uygulamalar için API tasarım rehberi. REST vs GraphQL karşılaştırması, pagination, versioning, cache stratejileri ve offline-first yaklaşımlar.
Mobil İçin API Neden Farklı?
- Sınırlı bant genişliği (mobil veri)
- Yüksek latency (kablosuz ağ)
- Batarya tüketimi (her ağ çağrısı enerji harcar)
- Farklı ekran boyutları = farklı veri ihtiyacı
- Bağlantı kopmaları (tünel, asansör, metro)
- 2026 itibarıyla edge computing ve CDN tabanlı API'lar yaygınlaşıyor
REST API
Avantajları
- Basit ve anlaşılır
- HTTP standartlarına dayalı
- Cache mekanizması kolay (HTTP cache)
- Geniş araç ve kütüphane desteği
- Öğrenmesi kolay
Dezavantajları
- Over-fetching: İhtiyaçtan fazla veri geliyor
- Under-fetching: Birden fazla istek gerekiyor
- Versiyon yönetimi (/v1, /v2)
- Her endpoint ayrı tasarlanmalı
REST Best Practices (Mobil)
- Pagination kullan (cursor-based önerilir - offset ile consistency sorunları olabilir)
- Field filtering: ?fields=id,name,image
- Sparse fieldsets: Sadece gerekli alanları döndür
- Gzip/Brotli compression
- ETag ile conditional request (304 Not Modified)
- Consistent error format:
{ "error": { "code": "INVALID_EMAIL", "message": "..." } }
- Rate limiting header'ları: X-RateLimit-Limit, X-RateLimit-Remaining
GraphQL
Avantajları
- Tam olarak ihtiyacın kadar veri: Client ne isterse o gelir
- Tek endpoint (/graphql)
- Güçlü tip sistemi (schema)
- Birden fazla kaynağı tek istekte al
- Gerçek zamanlı (subscriptions)
- Introspection ile self-documenting API
Dezavantajları
- Öğrenme eğrisi (query language, schema tasarımı)
- Cache daha karmaşık (Apollo Client normalized cache ile çözülür)
- File upload standart değil (multipart spec gerekli)
- N+1 query problemi (backend'de DataLoader ile çözülür)
- Over-engineering riski (basit uygulamalar için)
Karşılaştırma
| Özellik | REST | GraphQL |
|---|
| Öğrenme | Kolay | Orta |
| Over-fetching | Yaygın | Yok |
| Cache | Kolay (HTTP) | Karmaşık (normalized) |
| File upload | Standart (multipart) | Karmaşık |
| Real-time | Yok (WebSocket ayrı) | Subscription |
| Araçlar | Çok geniş | Büyüyor |
| Versioning | URL bazlı | Schema evolution |
| Monitoring | Basit (endpoint bazlı) | Karmaşık (query bazlı) |
Ne Zaman Hangisi?
REST Tercih Et
- Basit CRUD uygulamaları
- Küçük ekip, hızlı geliştirme
- Güçlü cache gereksinimi
- Backend deneyimi az
- Public API sunacaksan
GraphQL Tercih Et
- Karmaşık veri ilişkileri
- Birden fazla platform (web + mobile + tablet)
- Farklı ekranlar farklı veri istiyor
- Hızlı iterasyon gerektiren ürün
- Mikro-servis mimarisi (BFF pattern)
Mobil Özel İpuçları
- Minimum request sayısı (batarya + performans)
- Response boyutunu minimize et (gereksiz alan gönderme)
- Offline cache stratejisi (AsyncStorage, MMKV, SQLite, WatermelonDB)
- Retry mekanizması (exponential backoff: 1s → 2s → 4s → 8s)
- Request timeout ayarla (10-30 saniye)
- Optimistic update ile algılanan hızı artır
- Background sync ile offline değişiklikleri senkronize et
- Certificate pinning ile güvenlik (MITM koruması)
Popüler HTTP Client'lar
| Client | Platform | Özellik |
|---|
| Axios | Cross-platform | İnterceptor, retry, cancel token |
| Ky | Cross-platform | Modern, küçük boyut |
| Apollo Client | GraphQL | Normalized cache, React hooks |
| TanStack Query | REST/GraphQL | Cache, retry, background refetch |
| URQL | GraphQL | Hafif, extensible, exchange system |
API Güvenliği
- HTTPS: Her zaman (HTTP asla)
- Authentication: JWT token veya API key
- Token refresh: Access token + refresh token pattern
- Rate limiting: Brute force koruması
- Input validation: Server-side validation (client validation yetmez)
- CORS: Web client'lar için (mobil native'de gerekli değil)
API tasarımında "perfect" yoktur. Uygulamanızın karmaşıklığına ve ekibinizin deneyimine göre seçin. Başlangıçta REST, karmaşıklaştıkça GraphQL'e geçiş yaygın bir patterndir.
İlgili Konular
