REST mi GraphQL mi tercih etmeliyiz?

Ekran sayısı sınırlı ve veri şekli öngörülebilirse REST daha az yönetim yükü getirir. Ekranlar birbirinden çok farklı alan kümeleri istiyorsa veya istemci ekibi bağımsız hızlanmak istiyorsa GraphQL avantaj sağlar. Kararı ekran listesine bakarak veriyoruz; ikisini de geliştiriyoruz ve gerektiğinde REST üzerine tek bir toplu ekran uç noktası eklemek çoğu ihtiyacı karşılıyor.

Kullanıcıların eski sürüm uygulaması güncellemede bozulur mu?

Doğru kurulduğunda bozulmaz. Mağazadan güncelleme yapmayan kullanıcılar her zaman olacağı için API'yi sürümlü tasarlıyoruz: mevcut alanların anlamı değişmez, yeni alanlar eklenerek ilerlenir. Kırıcı bir değişiklik gerektiğinde yeni sürüm uç noktası açılır, eskisi ilan edilen bir süre boyunca çalışmaya devam eder ve kullanım oranı izlenir.

Uygulamanın internetsiz çalışması mümkün mü?

Kısmen ve planlanarak mümkün. Okuma tarafı için veriyi istemcide önbelleğe alıp değişiklikleri damgalı (timestamp/sürüm) biçimde çekmek yeterlidir. Yazma tarafı daha dikkat ister: çevrimdışı yapılan işlemler kuyruğa alınır, bağlantı gelince benzersiz anahtarla gönderilir ve çakışma kuralı devreye girer. Hangi ekranların çevrimdışı çalışacağına baştan karar vermek, sonradan eklemekten çok daha ucuz.

Push bildirim altyapısı bu işin parçası mı?

Evet. Cihaz kaydı, konu/segment yönetimi ve bildirim tetikleme uç noktaları backend'in parçasıdır; gönderim ise Apple ve Google'ın bildirim servisleri üzerinden yapılır. Bildirimin içeriğini üreten kural (ör. sipariş durumu değişti) API tarafında tanımlanır, böylece aynı kural hem mobil hem web için tek yerde durur.

Uygulamayı başka bir ekip yazacak; nasıl birlikte çalışırız?

İlk teslimimiz kod değil, sözleşme oluyor: uç nokta listesi ve OpenAPI dokümanı. Buna bağlı bir mock sunucu açıyoruz; mobil ekip gerçek servisler hazır olmadan arayüzü geliştirmeye başlayabiliyor. Sonrasında sandbox ortamı, Postman koleksiyonu ve sürüm notlarıyla ilerliyoruz. Uygulamanın kendisini de biz geliştiriyorsak süreç mobil yazılım geliştirme tarafıyla tek plan altında yürüyor.

Çözüm · Mobil backendAPI Geliştirme

Uygulama hazır. Peki arkasında ne var?

Mobil Uygulama İçin Backend API Geliştirme

Mobil istemci tarayıcı gibi davranmaz: bağlantı kopar, kullanıcı güncellemeyi geciktirir, küçük ekran küçük yanıt ister. Backend'i bu üç gerçeğe göre tasarlıyoruz — sürümlü uç noktalar, kimlik doğrulama, önbellek ve çevrimdışı kuyruk ile. İlk teslim kod değil, yazılı uç nokta sözleşmesi.

Ücretsiz Keşif Görüşmesi Hemen Ara · +90 (532) 476 9667

WhatsApp'tan yazın Uç nokta planınızı oluşturun

Önce OpenAPI sözleşmesi, sonra kod
Mock sunucu ile paralel geliştirme
Sürümlü ve geriye uyumlu tasarım
Kaynak kod ve şema sizin

Mobilde farklı olan ne?

Aynı API, mobilde neden aynı sonucu vermiyor?

Mobil uygulamanın backend'i, web uygulamasının backend'inden teknoloji olarak değil, varsayımlar olarak ayrılıyor. Aşağıdaki maddeler, mobil projelerde en sık geç fark edilen noktalar.

← Görseli yana kaydırın →

Ekran dört alan istiyor, yanıt yirmi iki alan getiriyorWeb için yazılmış uç noktalar tüm nesneyi döndürür. Mobilde bu, gereksiz veri kullanımı, daha uzun yükleme ve daha hızlı biten pil demektir.
Bir ekran için altı ayrı istek atılıyorHer bileşen kendi isteğini yaptığında açılış süresi ağ gecikmesinin katlarına çıkıyor. Mobilde gecikme, sunucu hızından çok tur sayısına bağlı.
Kullanıcı güncellemiyor, API değişiyorMağazadaki sürümle sahadaki sürüm hiçbir zaman aynı olmuyor. Sürümleme düşünülmeden yapılan bir alan değişikliği, eski uygulamaları tek seferde kırıyor.
Bağlantı koptuğunda işlem kayboluyorAsansörde gönderilen form, tünelde kaydedilen not. Çevrimdışı kuyruk yoksa kullanıcı işlemi yaptığını sanıyor, veri hiçbir yere ulaşmıyor.
Oturum ya çok kısa ya hiç bitmiyorKısa ömürlü token yenileme akışı yoksa kullanıcı sürekli yeniden giriş yapar; uzun ömürlü token ise cihaz kaybında ciddi bir güvenlik açığına dönüşür.
Hata mesajı ekranda gösterilemiyorSunucu yalnız teknik hata döndürdüğünde istemci ne yazacağını bilemez. Hata sözlüğü tanımlı değilse her ekran kendi tahminini yazar.

Yaklaşımımız

Önce uç nokta sözleşmesi, sonra satır kod.

Mobil projelerde en pahalı gecikme, arayüz ile servis arasındaki varsayım farkından çıkıyor. Sözleşmeyi ilk haftada yazıp mock sunucuyla açtığımızda iki ekip birbirini beklemeden ilerliyor.

Ekran envanteriUygulamanın her ekranı için hangi verinin gerektiğini listeliyoruz. Uç nokta tasarımı ekrandan türüyor; tersi değil.TeslimEkran–veri tablosuAlan listesiYetki ihtiyaçları
Sözleşme ve mockOpenAPI dokümanı yazılıyor ve buna bağlı bir mock sunucu açılıyor. Mobil ekip gerçek servisleri beklemeden arayüzü kurmaya başlıyor.TeslimOpenAPI dokümanıMock sunucuÖrnek yanıtlar
Kimlik ve yetkiKısa ömürlü erişim, uzun ömürlü yenileme anahtarı; cihaz bazlı oturum listesi ve çıkışta iptal. Rol ve kapsam kuralları burada tanımlanıyor.TeslimAuth akışıOturum yönetimiRol/kapsam tablosu
Performans ve dayanıklılıkSayfalama, önbellek başlıkları, toplu ekran uç noktaları ve çevrimdışı kuyruk kuralları. Yanıt boyutu ve tur sayısı ölçülerek azaltılıyor.TeslimSayfalama kurallarıÖnbellek politikasıÇevrimdışı senaryo notu
Sürüm ve izlemeSürümleme politikası, kırıcı değişiklik prosedürü ve sürüm bazlı kullanım izleme. Hangi uygulama sürümünün hâlâ sahada olduğu görünür oluyor.TeslimSürüm politikasıKullanım panosuPostman koleksiyonu

İmza aracı · Uç nokta planlayıcı

Uygulamanızın API yüzeyini şimdi görün

Uygulamanızda olacak özellikleri işaretleyin; ekranda o özelliklerin gerektirdiği uç nokta listesi, kimlik doğrulama ihtiyacı ve arka plan işleri belirsin. Bu liste keşif görüşmesinin gündemini doğrudan oluşturur. Hiçbir veri kaydedilmez.

Uygulamanızda hangi özellikler olacak?

İlk sürümde olmayacak ama altı ay içinde planladığınız özellikleri de işaretleyin — sürümleme ve veri modeli kararları buna göre değişir.

Oluşan API yüzeyi

Uç nokta12

Kimlik doğrulamalı5

Gerçek zamanlı kanal0

Arka plan işi0

Kimlik ve oturum

POST/v1/auth/registeraçık
POST/v1/auth/loginaçık
POST/v1/auth/refreshaçık
POST/v1/auth/password/resetaçık
POST/v1/auth/logoutauth

Kullanıcı profili

GET/v1/meauth
PATCH/v1/meauth
POST/v1/me/avatarauth
DELETE/v1/meauth

Katalog / içerik listesi

GET/v1/itemsaçık
GET/v1/items/{id}açık
GET/v1/categoriesaçık

Bu seçimlerde karara bağlanması gerekenler

Kimlik ve oturum: Erişim anahtarının ömrü ve cihaz başına oturum sayısı baştan karara bağlanmalı.
Kullanıcı profili: Hesap silme talebi, mağaza kuralları ve kişisel veri mevzuatı açısından gerçekten uygulanabilir olmalı.
Katalog / içerik listesi: Sayfalama imleç (cursor) tabanlı kurulursa liste kaydırmada tekrar eden kayıt sorunu yaşanmaz.

Bu yüzey için teslim edilenler

OpenAPI dokümanı ve canlı Swagger arayüzü
Mock sunucu (mobil ekip beklemeden başlar)
Postman koleksiyonu ve örnek yanıtlar
Hata kodu sözlüğü (istemcide gösterilebilir mesajlar)
Sürümleme politikası ve kırıcı değişiklik prosedürü
Sandbox ortamı ve kabul testi

Buradaki uç nokta listesi, seçtiğiniz özelliklerin tipik API yüzeyinden türetilen örnek bir taslaktır; süre, fiyat veya kesin kapsam taahhüdü değildir. Gerçek liste, ekran envanteri çıkarıldıktan sonra netleşir ve genelde birkaç uç nokta eklenip birkaçı birleşir.

Bu planla teklif isteyin →İletişim kanallarını görün

Mobilin üç gerçeği

Bağlantı kopar, pil biter, ekran küçüktür.

Bu üç cümle bütün mobil backend kararlarının arkasında duruyor. Aşağıda her biri için somut olarak ne yaptığımız var.

← Görseli yana kaydırın →

Bağlantı koparÇevrimdışı kuyruk, benzersiz işlem anahtarı ve çakışma kuralı. Kullanıcı bağlantısız yaptığı işlemi kaybetmez; bağlantı gelince kuyruk boşalır.
Pil ve veri sınırlıdırEkran başına biçilmiş yanıtlar, sayfalama, önbellek başlıkları ve koşullu istek. Değişmemiş veri yeniden indirilmez.
Ekran küçüktürAlan listesi ekrandan türetilir; gereksiz ilişkiler yanıta girmez. Bir ekran için altı istek yerine tek toplu uç nokta değerlendirilir.
Cihaz kaybolabilirKısa ömürlü erişim anahtarı, iptal edilebilir yenileme anahtarı ve cihaz bazlı oturum listesi. Kullanıcı kaybolan cihazın oturumunu kapatabilir.

← Görseli yana kaydırın →

Bu kararların hepsi kabul kriterlerine yazılır. Güvenlik tarafında dışarıdan doğrulama isteyen ekipler için sızma testi rehberimiz süreci nasıl işlettiğimizi anlatıyor.

Sürümleme

Sahadaki uygulama, mağazadaki uygulama değildir.

Mobilde güncellemeyi kullanıcı yapar. Bu yüzden API'nin ilk kuralı şu olur: bugün yayınlanan sürüm, yarın da aynı yanıtı vermeye devam etmeli.

← Görseli yana kaydırın →

Alan silinmez, eklenirYayınlanmış bir alan kaldırılmaz; kullanımdan kalkacaksa önce 'artık kullanılmıyor' olarak işaretlenir.
Anlam değiştirilmezVar olan bir alanın birimi veya biçimi değiştirilmez; gerekiyorsa yanına yeni bir alan gelir.
Kırıcı değişiklik yeni yoldaZorunlu bir kırılma varsa /v2 açılır; /v1 ilan edilen süre boyunca yaşamaya devam eder.
Kapanış kararı veriyleEski sürümün kapanma tarihi, o sürümü kullanan cihaz oranı izlenerek belirlenir.

Yaklaşımımız ekleyerek ilerlemek: mevcut alanların adı ve anlamı sabit kalır, yeni ihtiyaçlar yeni alan olarak gelir. Kırıcı bir değişiklik kaçınılmazsa yeni sürüm yolu açılır ve eski sürüm ilan edilen bir süre boyunca çalışmaya devam eder. Bu sürede sürüm bazlı kullanım izlenir; kapanış kararı tahminle değil, sahadaki kullanım oranıyla verilir.

Uygulamanın kendisini de biz geliştiriyorsak süreç mobil yazılım geliştirme tarafıyla tek plan altında yürür; native ve cross-platform tercihinin etkilerini mobil uygulama geliştirme süreci rehberimizde anlattık. Backend'in çalışacağı ortam kararı için bulut sunucu kiralama tarafına ve hosting, VPS, bulut ve dedicated farkı yazımıza bakabilirsiniz.

Örnek plan

Örnek bir ilk faz: sözleşme, auth ve üç modül

Aşağıdaki plan, kimlik doğrulama ve üç işlevsel modül içeren tipik bir ilk faz için hazırlanmış örnektir. Sizin planınız ekran envanteri çıktıktan sonra netleşir ve sözleşmede yazılı tarihe bağlanır.

← Görseli yana kaydırın →

Örnek 8 haftalık mobil backend planı ve haftalık çıktıları
Hafta	Ne yapılır	Hafta sonunda elinizde ne olur
1. hafta	Ekran envanteri ve veri modeli	Ekran–veri tablosu, alan listesi
2. hafta	OpenAPI sözleşmesi ve mock	Mock sunucu, örnek yanıtlar
3. hafta	Kimlik ve oturum	Giriş, yenileme, çıkış akışı
4–5. hafta	Çekirdek modüller	Liste, detay ve işlem uç noktaları
6. hafta	Push ve arka plan işleri	Cihaz kaydı, bildirim tetikleyicileri
7. hafta	Performans ve çevrimdışı	Sayfalama, önbellek, kuyruk davranışı
8. hafta	Kabul testi ve devir	Sandbox, Postman, sürüm politikası

İlk faz kapandıktan sonra yeni modüller aynı sözleşmeye eklenerek ilerler; sürümleme kuralı tanımlı olduğu için sahadaki uygulamalar etkilenmez.

Devamı

Kararı verirken işinize yarayacak sayfalar

Hizmet sayfasına dön →

SSS

Sık sorulanlar

Mevcut API'nin kullanımı, REST/GraphQL tercihi, sürümleme, çevrimdışı çalışma ve ekiplerin birlikte çalışması hakkında en çok sorulanlar.

Bazen kullanılabilir, ama çoğu zaman verimli olmaz. Web arayüzü için tasarlanmış uç noktalar genellikle ekranın ihtiyacından çok daha fazla alan döndürür; mobil tarafta bu, hem veri kullanımı hem pil tüketimi hem de algılanan yavaşlık demektir. Yaygın çözüm, mevcut servislerin üzerine mobil için derlenmiş ince bir katman koymak: aynı veri kaynağı, ekran başına biçilmiş yanıtlar.

Ekran listenizi gönderin, uç nokta taslağını birlikte çıkaralım

Elinizde tasarım, akış şeması ya da yalnız bir fikir listesi olması yeterli. İlk görüşmede ekranlardan uç noktalara geçiyor, ilk faz için gerçekçi bir kapsam çıkarıyoruz. Keşif görüşmesi ücretsizdir ve sizi bağlamaz.

✓ Keşif görüşmesi ücretsiz
✓ Önce sözleşme, sonra kod
✓ Mock sunucu ilk fazda açılır

Ücretsiz Keşif Görüşmesi İletişim Formu

Telefon+90 (532) 476 9667 WhatsAppMesaj gönderin E-postainfo@w3.net.trMaltepe / İstanbul · Hafta içi 09:00–19:00

API Geliştirme

Mobil ekibi bekletmeyen bir backend kuralım

Ekran envanteriyle başlıyor, OpenAPI sözleşmesi ve mock sunucuyla devam ediyor, sürümlü ve çevrimdışına hazır bir API ile kapatıyoruz.

✓ Keşif görüşmesi ücretsiz✓ Önce sözleşme, sonra kod✓ Mock sunucu ilk fazda açılır

Ücretsiz Keşif Görüşmesi Hizmeti İncele