REST mi GraphQL mi? Hangi API yaklaşımını seçmelisiniz?

REST ve GraphQL aynı temel sorunu çözer: Bir istemcinin HTTP üzerinden sunucudan veri istemesini sağlamak. Ancak bunu farklı ödünleşimlerle yaparlar ve aralarındaki seçim çoğu zaman gerektiğinden fazla ideolojik bir tartışmaya dönüşür. Hiçbiri mutlak olarak daha iyi değildir. Her biri belirli ürün ve ekip yapılarına diğerinden daha iyi uyar.

REST nasıl çalışır, nerede güçlüdür?

REST, bir API'yi kaynaklar etrafında düzenler (bir kullanıcı için bir URL, bir sipariş için bir URL, bir ürün listesi için bir URL) ve bu kaynaklar üzerinde işlem yapmak için standart HTTP metotlarını (GET, POST, PUT, DELETE) kullanır. Web API'leri için o kadar uzun süredir varsayılan yaklaşım ki araçları, önbellekleme davranışı ve ekiplerin aşinalığı tamamen olgunlaşmış durumda. Her HTTP önbelleği, CDN ve tarayıcı, bir GET isteğini URL'sine göre önbelleğe almayı zaten bilir; bu, REST'in bedavaya sahip olduğu gerçek ve pratik bir avantajdır.

REST'in zorlandığı yer, istemcinin birden fazla kaynağa yayılan verilere ihtiyaç duyduğu durumlardır. Bir kullanıcının profilini, son beş siparişini ve her siparişin kalemlerini gösteren bir mobil uygulama ekranı, üç dört ayrı REST çağrısına ya da yalnızca o ekran için yazılmış özel bir birleşik uç noktaya ihtiyaç duyabilir. Ürün büyüdükçe bu uç noktanın da ekrana özel diğer tüm uç noktalarla birlikte bakımı yapılmak zorundadır.

GraphQL nasıl çalışır, nerede güçlüdür?

GraphQL modeli tersine çevirir: Her uç noktanın hangi biçimde veri döndüreceğine sunucu karar vermez; istemci, birbiriyle ilişkili birden fazla kaynağı da kapsayabilecek şekilde tam olarak ihtiyaç duyduğu alanları tanımlayan bir sorgu gönderir ve tam olarak bunu alır, ne eksik ne fazla. Bu tek istekteki esneklik öne çıkan özelliktir ve her biri aynı temel verinin biraz farklı bir kesitine ihtiyaç duyan çok sayıda istemci ekranı ya da uygulaması (web, iOS, Android) olan ürünler için gerçekten değerlidir; çünkü tek bir esnek şema, özel uç noktaların çoğalmasına yol açmadan hepsine hizmet edebilir.

Bedelleri de gerçektir. Önbelleğe alma daha zordur; çünkü bir GraphQL API genellikle önbelleğe alınabilir çok sayıda GET URL'si yerine tek bir POST uç noktasıdır. Bu nedenle standart HTTP önbelleğine güvenmek yerine amaca özel önbellekleme (persisted query'ler, Apollo veya Relay gibi istemci tarafında normalize edilmiş önbellekler) gerekir. Sorgu karmaşıklığının sunucu tarafında aktif olarak yönetilmesi gerekir; çünkü bir istemci teknik olarak, sıradan bir REST uç noktasının baştan asla izin vermeyeceği derin iç içe geçmiş, maliyetli bir sorgu gönderebilir. Ayrıca GraphQL'e yeni başlayan bir ekip için öğrenme eğrisi (şema tasarımı, resolver'lar, istemci araçları) REST'inkinden daha diktir.

Pratik karar

• REST'i seçin: Veri modeliniz daha basitse, az sayıda istemci türünüz varsa, standart HTTP önbelleklemesine ve araçlarına yaslanmak istiyorsanız ya da ekibiniz REST'e zaten hâkimse ve ürün daha fazlasını gerektirmiyorsa.
• GraphQL'i seçin: Aynı backend'den birbirinden çok farklı birkaç istemci uygulamaya hizmet veriyorsanız, veri modeliniz gerçekten ilişkiselse ve istemcilerin bu ilişkiler arasında tek istekte gezinmesi sık gerekiyorsa ya da REST ile fazla veya eksik veri çekme (over-fetching / under-fetching) varsayımsal değil, gerçek ve tekrarlayan bir sorun hâline geldiyse.
• Hiçbiri tüm sistem için ya hep ya hiç türünden bir tercih olmak zorunda değil. Pek çok gerçek ürün, basit CRUD servisleri için REST'i, istemciye dönük sorgular için de bunların önünde bir birleştirme katmanı olarak GraphQL'i kullanır; ya da tam tersini.

API yaklaşımından daha önemli olan

Hangisini seçerseniz seçin, bir API'nin uzun vadede üzerinde çalışmanın keyifli olup olmayacağını belirleyen unsurlar aynıdır: açık ve tutarlı adlandırma, her şeyin 200 döndürmesi yerine düzgün hata yönetimi, makul sayfalama ve gerçekten güncel tutulan dokümantasyon. İyi tasarlanmış bir REST API, kötü tasarlanmış bir GraphQL API'yi her zaman geçer; tersi de geçerlidir. Biçim, arkasındaki disiplinden çok daha küçük bir etkendir.

Yalnızca daha popüler olanı değil, ürünün gerçek yapısına uygun API mimarisini seçmek, Burncode'da geliştirdiğimiz her backend'de yürüttüğümüz yazılım ve web geliştirme çalışmalarının bir parçasıdır. Çünkü bu konudaki yanlış bir tercihi, bir düzine istemci ona bağımlı hâle geldikten sonra geri almak çok pahalıya patlar.