- Konu sahibi
- #1
REST, kaynakları ayrı URL’ler ve HTTP yöntemleri üzerinden sunan bir API yaklaşımıdır; GraphQL ise API için bir sorgu dili ve bu sorguları şema üzerinde yürüten çalışma modelidir; çoğunlukla tek HTTP uç noktasından sunulur, ancak bu taşıma biçimi dilin zorunlu şartı değildir. REST’te sunucu çoğunlukla hangi verinin döneceğini belirler. GraphQL’de istemci, şema içinde izin verilen alanları belirterek yanıtın şeklini daha doğrudan kontrol eder. Küçük ve kaynakları net bir uygulamada REST genellikle daha basit bir başlangıçtır; farklı istemcilerin farklı veri ihtiyaçları varsa GraphQL daha esnek olabilir.
REST’te her kaynak için URL’ler ve HTTP yöntemleri kullanılır. Örneğin bir blog API’sinde
GraphQL’de istemci genellikle
Bu sorgu, şemada post(id
ile title ve author alanlarının tanımlı olduğu varsayımına dayanır; tek başına çalışan API değildir. GraphQL yanıtı normalde sonucu data anahtarında taşır; yürütme hatalarıyla kısmi data ve errors birlikte bulunabilir. Şema doğrulaması erişim yetkisi yerine geçmez. Bu, istemcinin gereksiz alanları almamasını sağlayabilir; ancak sunucunun şema, sorgu doğrulama, yetkilendirme ve sorgu maliyeti yönetimini doğru kurmasını gerektirir.
Bir mobil uygulamanın yazı listesindeki başlık, yazar adı ve yorum sayısını; yazı ayrıntı ekranında ise içerik, etiketler ve son yorumları gösterdiğini varsayalım.
REST ile liste için
GraphQL ile istemci liste ekranı için yalnızca
Bu fark, GraphQL’in her durumda daha hızlı olduğu anlamına gelmez. Ağ çağrılarının azalması avantaj sağlayabilir; fakat karmaşık sorguların sunucuda oluşturduğu işlem, veritabanı sorguları ve önbellekleme maliyeti ayrıca değerlendirilmelidir.
Kararı yalnızca “tek istek mi, çok istek mi?” sorusuna bağlamayın. Ekip, veri modeli, önbellek ihtiyacı ve istemci çeşitliliği birlikte değerlendirilmelidir.
Bu tablo kesin bir kural değil, başlangıç kararını kolaylaştıran bir çerçevedir. Önce en kritik ekranların veri ihtiyaçlarını ve beklenen sorgu biçimini çıkarın. REST seçerseniz kaynak URL’lerini, HTTP yöntemlerini ve hata yanıtlarını tutarlı tasarlayın. GraphQL seçerseniz şemayı, alan bazlı yetkilendirmeyi, sorgu derinliği veya maliyeti sınırlandırmayı ve çözümleyicilerin veritabanına gereksiz tekrar sorgu göndermemesini baştan planlayın.
REST’i yalnızca JSON sanmak: REST bir mimari stildir; istemci-sunucu ayrımı, stateless istekler, önbellek ve uniform interface gibi kısıtları vardır. HTTP+JSON kullanan her API bu kısıtları bütünüyle karşılamaz; bu rehber yaygın kaynak odaklı HTTP API kullanımını karşılaştırır.
GraphQL’i tek uç nokta olduğu için basit kabul etmek: URL sayısı azalırken şema yönetimi, sorgu maliyeti, yetkilendirme ve izleme daha önemli hâle gelir.
GraphQL’de her alanı herkese açmak: İstemcinin alan seçebilmesi, her alanı yetkisiz okuyabilmesi anlamına gelmez. Yetki kontrolleri çözümleyici veya uygun servis katmanında uygulanmalıdır.
Sadece istek sayısını ölçmek: Yanıt boyutunu, toplam sorgu süresini, veritabanı yükünü ve hata oranını birlikte inceleyin. Gerçek kullanım şekli görülmeden bir yaklaşımın kesin olarak daha iyi olduğu söylenemez.
GraphQL sorgu seçimi, veritabanının mutlaka az iş yapacağı anlamına gelmez. Alan çözümleyicilerinde N+1 sorgu oluşabilir; batching ve ölçüm gerekir. HTTP üzerinden GET/persisted query ile önbellek kurulabilir; kişiye özel veride cache anahtarı ve erişim sınırları ayrıca korunur.
Nasıl çalışırlar?
REST’te her kaynak için URL’ler ve HTTP yöntemleri kullanılır. Örneğin bir blog API’sinde
GET /posts/42 belirli bir yazıyı, POST /posts yeni yazı oluşturmayı, PATCH /posts/42 mevcut yazıyı değiştirmeyi ifade edebilir. Yanıt çoğunlukla JSON’dur. İstemci, gerekli veriyi almak için birden fazla kaynağa istek göndermek zorunda kalabilir.GraphQL’de istemci genellikle
/graphql gibi tek bir uç noktaya sorgu gönderir. Sorguda yalnızca ihtiyaç duyulan alanlar belirtilir:
Kod:
query {
post(id: 42) {
title
author {
name
}
}
}Bu sorgu, şemada post(id
ile title ve author alanlarının tanımlı olduğu varsayımına dayanır; tek başına çalışan API değildir. GraphQL yanıtı normalde sonucu data anahtarında taşır; yürütme hatalarıyla kısmi data ve errors birlikte bulunabilir. Şema doğrulaması erişim yetkisi yerine geçmez. Bu, istemcinin gereksiz alanları almamasını sağlayabilir; ancak sunucunun şema, sorgu doğrulama, yetkilendirme ve sorgu maliyeti yönetimini doğru kurmasını gerektirir.Somut örnek: yazı listesi ve ayrıntısı
Bir mobil uygulamanın yazı listesindeki başlık, yazar adı ve yorum sayısını; yazı ayrıntı ekranında ise içerik, etiketler ve son yorumları gösterdiğini varsayalım.
REST ile liste için
GET /posts, her yazının yazarı için ayrıca GET /users/{id} ve yorumlar için GET /posts/{id}/comments çağrıları gerekebilir. Bu REST tasarımına bağlı bir olasılıktır. REST uç noktası yazar/yorum sayısını yanıtına ekleyebilir, alan seçimi veya toplu erişim sağlayabilir; REST mutlaka her ilişki için ayrı ağ isteği gerektirmez.GraphQL ile istemci liste ekranı için yalnızca
id, title, author { name } ve commentCount alanlarını ister. Ayrıntı ekranı farklı bir sorguyla içerik ve yorum alanlarını da seçer. Böylece aynı API, farklı ekranların veri ihtiyacına göre farklı yanıtlar üretebilir.Bu fark, GraphQL’in her durumda daha hızlı olduğu anlamına gelmez. Ağ çağrılarının azalması avantaj sağlayabilir; fakat karmaşık sorguların sunucuda oluşturduğu işlem, veritabanı sorguları ve önbellekleme maliyeti ayrıca değerlendirilmelidir.
Hangi durumda hangisini seçmeli?
Kararı yalnızca “tek istek mi, çok istek mi?” sorusuna bağlamayın. Ekip, veri modeli, önbellek ihtiyacı ve istemci çeşitliliği birlikte değerlendirilmelidir.
| İhtiyaç | Daha uygun başlangıç | Gerekçe |
|---|---|---|
| Kaynaklar ve işlemler net, API dış kullanıma açılacak | REST | URL, HTTP yöntemleri ve hata ayıklama modeli kolay anlaşılır |
| Web, mobil ve farklı ekranların veri ihtiyaçları değişiyor | GraphQL | İstemci gerekli alanları sorgulayabilir |
| HTTP önbelleklemesi basit tutulmak isteniyor | REST | Kaynak URL’leri üzerinden önbellekleme daha doğrudan kurulabilir |
| İlişkili veriler tek ekran için birlikte gerekiyor | GraphQL değerlendirilebilir | İlişkili alanlar tek sorgu yapısında alınabilir |
Bu tablo kesin bir kural değil, başlangıç kararını kolaylaştıran bir çerçevedir. Önce en kritik ekranların veri ihtiyaçlarını ve beklenen sorgu biçimini çıkarın. REST seçerseniz kaynak URL’lerini, HTTP yöntemlerini ve hata yanıtlarını tutarlı tasarlayın. GraphQL seçerseniz şemayı, alan bazlı yetkilendirmeyi, sorgu derinliği veya maliyeti sınırlandırmayı ve çözümleyicilerin veritabanına gereksiz tekrar sorgu göndermemesini baştan planlayın.
Sık yapılan hatalar
REST’i yalnızca JSON sanmak: REST bir mimari stildir; istemci-sunucu ayrımı, stateless istekler, önbellek ve uniform interface gibi kısıtları vardır. HTTP+JSON kullanan her API bu kısıtları bütünüyle karşılamaz; bu rehber yaygın kaynak odaklı HTTP API kullanımını karşılaştırır.
GraphQL’i tek uç nokta olduğu için basit kabul etmek: URL sayısı azalırken şema yönetimi, sorgu maliyeti, yetkilendirme ve izleme daha önemli hâle gelir.
GraphQL’de her alanı herkese açmak: İstemcinin alan seçebilmesi, her alanı yetkisiz okuyabilmesi anlamına gelmez. Yetki kontrolleri çözümleyici veya uygun servis katmanında uygulanmalıdır.
Sadece istek sayısını ölçmek: Yanıt boyutunu, toplam sorgu süresini, veritabanı yükünü ve hata oranını birlikte inceleyin. Gerçek kullanım şekli görülmeden bir yaklaşımın kesin olarak daha iyi olduğu söylenemez.
GraphQL sorgu seçimi, veritabanının mutlaka az iş yapacağı anlamına gelmez. Alan çözümleyicilerinde N+1 sorgu oluşabilir; batching ve ölçüm gerekir. HTTP üzerinden GET/persisted query ile önbellek kurulabilir; kişiye özel veride cache anahtarı ve erişim sınırları ayrıca korunur.
