Mobil uygulama denince akla önce tasarım gelir. Renkler, ikonlar, animasyonlar... Oysa uygulaması olan bayilerle olmayanlar arasındaki gerçek fark ekran değil, arka taraftaki API disiplini. Uygulama sadece bir vitrin; siparişi oluşturan, stoğu kilitleyen, ödemeyi doğrulayan ve kodu teslim eden mantığın tamamı senin sunucunda duruyor. Yani mobil uygulamanın kalitesi, aslında e-pin satış scriptinin API tarafının ne kadar düzgün tasarlandığıyla ölçülür.
Sektörde yaygın bir yanlış var: "Sitemi WebView ile paketleyip uygulama yaparım" fikri. Bu yöntem ilk hafta çalışır gibi görünür, sonra mağaza politikaları, bildirim izinleri, oturum kopmaları ve ödeme akışındaki yönlendirmeler arka arkaya patlar. Doğru yol, siteyle aynı veritabanını kullanan ama kendi kurallarıyla konuşan gerçek bir API katmanıdır. Bu yazıda, bir dijital ürün satış yazılımı üzerine mobil API'nin nasıl kurulduğunu, hangi uç noktalara gerçekten ihtiyacın olduğunu ve nerede güvenlik açığı bıraktığını tek tek konuşuyoruz.
Mobil API ile sitenin kendi kodu neden aynı şey değil?
Web tarafında oturum çerezle taşınır, sayfa yenilenir, form gönderilir. Mobil tarafta ise durum tamamen farklıdır: uygulama arka planda uyur, ağ kopar, kullanıcı uçak moduna geçer, telefon değiştirir. Bu yüzden API'nin durumsuz (stateless) olması gerekir. Her istek kendi kimliğini taşımalı, sunucu tarafında "kim olduğunu hatırlayan" bir oturum beklentisi olmamalıdır. Bir başka fark da yanıt biçimidir: web HTML döner, mobil JSON bekler. Aynı iş mantığını iki farklı kabuktan sunmak için servis katmanı ayrımı şarttır. İş kuralı bir kez yazılır, hem web hem API aynı kuralı çağırır. Aksi halde stok düşürme mantığını iki yerde ayrı ayrı sürdürmek zorunda kalırsın ve er geç ikisi birbirinden ayrışır.
Token düzeni nasıl kurulmalı, neden tek anahtar yetmez?
En sık yapılan hata, kullanıcıya ömür boyu geçerli tek bir anahtar vermektir. O anahtar bir kez sızarsa, kullanıcının bakiyesi ve sipariş geçmişi tamamen açığa çıkar. Doğru kurgu ikili yapıdır: kısa ömürlü erişim token'ı (15-60 dakika) ve uzun ömürlü yenileme token'ı. Erişim token'ı her isteğin başlığında gider; süresi dolunca uygulama sessizce yenileme token'ıyla yeni bir tane alır. Kullanıcı bunu hiç fark etmez, ama çalınan bir token bir saat sonra çöpe döner. Buna ek olarak her cihaz için ayrı kayıt tutmalısın; böylece kullanıcı "telefonumu kaybettim" dediğinde tek bir cihazın erişimini iptal edebilirsin. Oturum iptalini cihaz bazında yapamayan bir yapı, güvenli sayılmaz.
| Uç nokta | Metot | Görevi | Yetki | Önbellek |
|---|---|---|---|---|
| /api/auth/login | POST | Giriş, token çifti üretir | Herkese açık | Yok |
| /api/auth/refresh | POST | Erişim token'ını yeniler | Yenileme token'ı | Yok |
| /api/catalog | GET | Kategori ve ürün listesi | Opsiyonel | 60-300 sn |
| /api/product/{id} | GET | Fiyat, stok, açıklama | Opsiyonel | 30 sn |
| /api/order | POST | Sipariş oluşturur, stok kilitler | Zorunlu | Yok |
| /api/order/{id} | GET | Durum ve teslim edilen kod | Zorunlu | Yok |
| /api/wallet | GET | Bakiye ve hareketler | Zorunlu | Yok |
| /api/device/push | POST | Bildirim jetonu kaydı | Zorunlu | Yok |
Stok senkronu nerede bozuluyor, aynı kod iki kişiye nasıl gidiyor?
Kâbus senaryosu şudur: uygulamada listelenen son ürünü iki kullanıcı aynı saniyede satın alır ve aynı e-pin kodu ikisine birden teslim edilir. Bunun sebebi neredeyse her zaman okuma ile yazma arasındaki boşluktur. Çözüm, stok kontrolünü uygulama katmanında değil veritabanı düzeyinde kilitle yapmaktır: kodu önce "rezerve" durumuna çek, sonra ödemeyi doğrula, en sonunda "teslim edildi" olarak kapat. Rezervasyonun da bir ömrü olmalı; ödenmeyen sipariş belli süre sonra stoğu serbest bırakmalıdır. Mobilde bu daha da kritiktir çünkü kullanıcı ödeme ekranında uygulamadan çıkıp geri döner, süreç yarım kalır. İyi bir epin yazılım mimarisinde stok, ödeme onayından önce kilitlenir ama tüketilmez.
Mobil API entegrasyonunda harcanan geliştirme eforunun dağılımı
- Kimlik doğrulama ve oturum yönetimi 45%
- Sipariş ve ödeme akışı 25%
- Katalog ve önbellekleme 20%
- Bildirim ve cihaz kaydı 10%
Push bildirim gerçekten satış getirir mi, yoksa sadece rahatsız mı eder?
Bildirimin değeri içeriğinde değil, zamanlamasındadır. "Kampanyamız başladı" bildirimi genellikle sessizce silinir; ama "siparişin teslim edildi, kodun hazır" bildirimi uygulamayı açtırır. Doğru sıralama şöyledir: önce işlemsel bildirimler (sipariş durumu, bakiye yükleme onayı, stok geldi uyarısı), sonra davranışsal olanlar (sepette unutulan ürün, fiyatı düşen paket). Pazarlama bildirimlerini en sona bırak. Ayrıca cihaz jetonlarını düzenli temizle: silinmiş uygulamalara bildirim göndermeye devam etmek, gönderim itibarını düşürür. Bir diğer ayrıntı, bildirim üzerine tıklandığında kullanıcıyı ana ekrana değil doğrudan ilgili sipariş sayfasına götürmektir; bu tek dokunuş, dönüşümü ciddi biçimde değiştirir.
API'ni /api/v1/ ile başlat. Sürüm ayrımı olmadan çıktığın bir API'de yaptığın her değişiklik, mağazada güncelleme yüklememiş kullanıcıların uygulamasını kırar. Sürümleme sonradan eklenebilecek bir şey değildir.
Güvenlikte hangi katmanlar olmazsa uygulaman açık kapı olur?
Mobil uygulama, kullanıcının cihazında çalıştığı için istemci tarafına yazdığın hiçbir şey gizli değildir. Uygulamanın içine gömdüğün anahtar, bir saat içinde çıkarılabilir. Bu nedenle gerçek koruma sunucuda olmalı. Olmazsa olmaz katmanlar şunlardır: her uç noktada oran sınırlama (rate limit), sipariş oluşturmada çift gönderim koruması için idempotency anahtarı, bakiye işlemlerinde sunucu tarafı fiyat doğrulaması ve şüpheli cihaz davranışında otomatik askıya alma. Özellikle fiyatı istemciden almak, sektörün klasik felaketidir: uygulama 1 TL gönderir, sunucu kabul eder, 500 TL'lik ürün 1 TL'ye satılır. Fiyat her zaman sunucuda hesaplanır, istemci sadece ürün kimliği gönderir. Sistemin bu katmanları nasıl karşıladığını özellikler bölümünde inceleyebilirsin.
| Kontrol maddesi | Amacı | Tamamlandı ölçütü |
|---|---|---|
| Sürümlenmiş uç nokta yapısı | Eski istemcileri kırmamak | Tüm yollar /v1 altında |
| Erişim + yenileme token çifti | Sızıntı riskini kısaltmak | Erişim ömrü 60 dk altında |
| Cihaz bazlı oturum iptali | Kayıp telefon senaryosu | Panelden tek cihaz kapatılabiliyor |
| Idempotency anahtarı | Çift sipariş oluşmasın | Aynı anahtar ikinci kez işlenmiyor |
| Sunucu tarafı fiyatlama | Manipülasyonu engellemek | İstemciden tutar kabul edilmiyor |
| Oran sınırlama | Kaba kuvvet ve kazıma | IP + kullanıcı bazlı limit aktif |
| Hata sözlüğü | Uygulama doğru mesaj göstersin | Her hata kodu belgelenmiş |
| Bildirim jetonu temizliği | Gönderim itibarı | Geçersiz jetonlar otomatik siliniyor |
Uygulamayı sıfırdan yazdırmak mı, hazır API'li bir yazılım almak mı mantıklı?
Karar, zamanın ve ekip büyüklüğünle ilgili. Sıfırdan yazdırmak istersen sadece uygulama değil, arka taraftaki tüm sipariş, bakiye, bayi ve teslimat mantığını da yeniden inşa etmen gerekir; bu genellikle aylarla ölçülen bir iştir. Hazır bir e-pin scripti üzerinde API katmanı zaten tanımlıysa, geriye sadece arayüz kalır ve iş bir kaç haftaya iner. Üstelik web ile uygulama aynı veritabanını kullandığı için stok, fiyat ve bayi iskontoları otomatik olarak senkron kalır. Maliyet karşılaştırmasını yaparken lisans bedelini değil, kaybedilen zamanı hesaba kat; bu pazarda altı ay, bir kampanya döneminin tamamı demektir. Paket farklarını fiyat bölümünden karşılaştırabilirsin.
Uygulamanı hazır bir API'nin üstüne kur
Sipariş, bakiye, stok ve teslimat mantığı hazır tanımlıyken geriye yalnızca arayüz kalır. Pinova'nın entegrasyon katmanını inceleyip kendi mobil yol haritanı netleştirebilirsin.
Mobil uygulama için ayrı bir veritabanı kurmam gerekir mi?
Hayır, hatta kurmamalısın. Uygulama ve web aynı veritabanını kullanmalı ki stok, fiyat ve bakiye tek kaynaktan okunsun. İki ayrı veri kaynağı, senkron sorunlarının en büyük nedenidir.
WebView ile paketlenmiş uygulama gerçekten sorun çıkarır mı?
Uzun vadede evet. Mağaza incelemelerinde sorun yaşama ihtimali yüksektir, bildirim ve derin bağlantı desteği sınırlıdır, ödeme yönlendirmelerinde oturum kopmaları görülür. Kısa vadeli bir köprü olarak kullanılabilir ama kalıcı çözüm değildir.
API dokümantasyonu olmadan geliştirici bulabilir miyim?
Bulursun ama pahalıya mal olur. Belgelenmemiş bir API'de geliştirici zamanının önemli kısmı keşfe gider. Uç nokta listesi, örnek istek-yanıt ve hata kodu sözlüğü hazırsa süre belirgin şekilde kısalır.
Bayilerim de uygulamayı kullanabilir mi?
Evet. Aynı API üzerinde rol bazlı yetkilendirme tanımlanırsa bayi kendi iskontolu fiyatını, bakiyesini ve sipariş geçmişini uygulamadan görür. Bunun için ayrı bir uygulama yazmak gerekmez, yalnızca yanıtların role göre şekillenmesi yeterlidir.
Mobil uygulama, e-pin işinde bir statü sembolü değil; müşterinin seni tekrar hatırlamasını sağlayan en kısa yol. Ama bu yolun taşları API tarafında döşenir: token düzeni, stok kilidi, sunucu tarafı fiyatlama ve düzgün bildirim akışı. Kendi uygulaman için hangi uç noktaların hazır geldiğini, sipariş akışının JSON tarafında nasıl göründüğünü ve bayi rollerinin API'ye nasıl yansıdığını incelemek istersen canlı demo üzerinden gerçek bir sipariş oluşturup akışı baştan sona takip edebilirsin.