Web ve Mobil İstemciler için Ortak Doğrulama Kuralları

Doğrulama neden kayar

Doğrulama uyumsuzluğuna düşmenin basit bir nedeni var: web ve mobil formlar genellikle farklı zamanlarda ve farklı kişiler tarafından oluşturulur. Bir ekip web sitesine hızlı bir kural ekler, başka bir ekip eski bir sürümü uygulamaya kopyalar ve herkes işine devam eder.

İlk başta fark küçük görünür. Sonra bir değişiklik bunu açığa çıkar. Şifre artık 8 yerine 12 karakter gerektiriyor. Telefon numarası artık ülke kodu istiyor. Eskiden isteğe bağlı olan bir alan artık zorunlu. Eğer sadece bir istemci güncellenirse, aynı müşteri bir cihazda geçerli veri girip diğerinde engellenebilir.

İşte bu yüzden paylaşılan doğrulama kuralları önemlidir. Onlar olmadan her istemci kendi gerçekliğini yaratır.

Saha örnekleri

Kayıt formları sorunu hızlıca gösterir. Web sitesinde "şirket adı" isteğe bağlı olabilir. Mobil uygulamada ise aylar önce yapılmış ekran hâlâ zorunlu tutuyor olabilir. Kullanıcı aynı formu iki kez doldurur, iki farklı sonuç alır ve ürünün bozuk olduğunu düşünür.

Bu genellikle kuralların birkaç yere kopyalanıp elle güncellenmesiyle olur. Yayın zamanlaması durumu daha da kötüleştirir. Web değişikliği bugün yayına girebilirken mobil düzeltme bir sonraki uygulama sürümünü bekleyebilir.

Uyumsuzluk genellikle temel yerlerde ortaya çıkar: zorunlu alanlar, format kontrolleri ve yaş, sipariş büyüklüğü veya indirim kuralları gibi iş limitleri. Destek ekipleri neden bir ekranın değeri kabul edip diğerinin reddettiğini açıklamak zorunda kalır. Zamanla kullanıcılar hata mesajlarına güvenmeyi bırakır, ekipler ise sürümlere güvenmeyi keser.

Sorunun kaynağı nadiren kuralın kendisidir. Sorun aynı kuralın çok fazla yerde yaşamasıdır.

Her yerde aynı kalması gerekenler

Bir form webde bir şekilde, mobilde başka şekilde davranıyorsa kullanıcı hemen fark eder. En güvenli yaklaşım hangi kuralların evrensel olduğunu belirlemek ve her istemcide bunları aynı tutmaktır.

Temelden başlayın. Bir alan bir cihazda zorunlu diğerinde isteğe bağlı olmamalıdır; bunun için çok net bir ürün gerekçesi yoksa. Format kontrolleri de eşleşmelidir. E-posta, telefon, tarih ve benzeri alanlar her yerde aynı deseni izlemelidir. Bir istemcinin telefon numarasında boşluklara izin verip diğerinin reddetmesi bile kafa karışıklığı yaratır.

Uzunluk sınırları ve izin verilen karakterler de aynı muameleyi hak eder. Bir kullanıcı adı mobilde 30 karakter kabul ederken webde sadece 20 kabul ediyorsa, kullanıcı bir istemcide kaydettiği veriyi diğerinde daha sonra düzenleyemez. Aynı sorun isimlerde, notlarda, kodlarda ve kimliklerde görünür.

İş kuralları da en az bunlar kadar önemlidir. Kullanıcıların belirli bir yaştan büyük olması, desteklenen bir bölgede olması veya belirli bir hesap durumuna sahip olması gerekiyorsa, bu kontroller her ekranda aynı çalışmalıdır.

Yazım her yerde birebir aynı olmak zorunda değil, özellikle küçük mobil ekranlarda, ancak anlam tutarlı olmalıdır. Bir uygulama "Geçerli bir tarih girin" derken diğeri "Tarih desteklenmiyor" diyorsa kullanıcılar kuralların farklı olduğunu düşünebilir.

Basit bir test iyi çalışır: kullanıcı aynı veriyi web ve mobilde girerse aynı sonucu ve düzeltme yönlendirmesini almalıdır.

Nihai kararı backend'e bırakın

Ön uçta hızlı geri bildirim faydalıdır, ancak son söz olmamalıdır. Verinin geçerli olup olmadığına her zaman backend karar vermelidir.

Web ve mobil istemciler bariz sorunları erken yakalamaya devam etmelidir. Eksik zorunlu alanları, yanlış e-posta formatını, imkânsız tarihleri ve açıkça aralık dışı değerleri işaretlemelidirler. Bu zaman kazandırır ve kullanıcıların Gönder'e basmadan önce hataları düzeltmesine yardımcı olur.

Ama backend tüm resmi görür. Canlı veri, hesap durumu, izinler, stok veya başka bir kullanıcının bir saniye önce değiştirdiği kayıtlarla bağlı iş kurallarını kontrol edebilir. Bir promosyon kodu telefonda geçerli görünebilir, ancak sunucu onun süresi dolmuş veya zaten kullanılmış olduğunu bilebilir.

Paylaşılan doğrulama kuralları iyi çalışsın istiyorsanız backend hataları her istemcinin anlayacağı bir biçimde döndürmelidir. "Geçersiz giriş" gibi belirsiz yanıtlar vermekten kaçının. İstikrarlı hata kodları veya kural isimleri ile birlikte net bir mesaj kullanın.

Birkaç örnek yeterlidir:

• required eksik alanlar için
• invalid_format hatalı e-posta veya telefon desenleri için
• out_of_range limit aşımları için
• not_allowed izin veya durum tabanlı kontroller için
• already_exists tekrar eden e-posta, kullanıcı adı veya kimlikler için

Bu isimler istemciler arasında sabit kalmalıdır. Bir uygulamada email_invalid, diğerinde invalid_email gibi küçük farklar gereksiz hatalara yol açar.

İyi bir backend testi basittir: biri UI'yi atlayıp isteği doğrudan API'ye gönderirse, aynı kötü veri aynı nedenle reddedilmelidir.

Tek bir gerçek kaynak oluşturun

En temiz çözüm tek bir kural kitabıdır. Her ekip her web formunun ve mobil ekranın içinde doğrulama yazarsa kurallar kayacaktır. Kural bir kez tanımlandığında ve her istemci aynı tanımı izlediğinde paylaşılan doğrulama kuralları daha iyi çalışır.

Bu paylaşılan kaynak bir şema, bir backend modeli veya merkezi bir ürün konfigürasyonu olabilir. Tam format alışkanlıktan daha az önemlidir. Alanı ekranlar inşa edilmeden önce bir kez tanımlayın. Alan adını, veri tipini, zorunlu olup olmadığını, formatı ve iş limitlerini birlikte tutun.

Ayrıca kuralları cihaz bazında değil iş nesnesi bazında gruplayın. Bir kullanıcı, sipariş, fatura veya kayıt isteği her yerde geçerli olacak bir kural setine sahip olmalıdır. Her nesne için alanları, zorunlu kontrolleri, format kurallarını, iş kısıtlarını ve backend'in döndürdüğü hata kodlarını kaydedin.

Bu, değişiklikleri daha güvenli hale getirir. İş, telefon numarasının isteğe bağlı olmasına karar verirse, iPhone, Android, web ve yönetim ekranlarında arama yapmak yerine tek bir paylaşılan tanımı güncellersiniz.

Versiyonlama da önemlidir. Kural değişiklikleri hâlâ müşterilerin telefonlarında yüklü olan eski uygulamaları bozabilir. Bir kuralı iz bırakmadan değiştirmek yerine değişikliği versiyonlayın ki backend yeni sürümler yayılırken eski istemcileri kısa süre destekleyebilsin.

Kısa bir inceleme adımı çoğu ekipten beklenenden daha fazla yardımcı olur. Bir kural değiştiğinde ürün hedefi doğrulayabilir, destek gerçek müşteri problemlerini işaretleyebilir; örneğin bir isim alanının yaygın noktalama işaretlerini reddetmesi veya adres kuralının çok katı olması gibi.

AppMaster ile geliştiriyorsanız bu yaklaşım doğal olarak uyar çünkü backend mantığı, web uygulamaları ve native mobil uygulamalar tek bir no-code platformda yönetilebilir. Fikir her yerde aynıdır: kuralları bir kez yazın, merkezi tutun ve her istemcinin bunları izlemesini sağlayın.

Basit bir yayılım planı

Doğrulama sapmasını düzeltmek için büyük bir yeniden yazmaya gerek yok. Bir formla başlayın ve kuralları açıkça tanımlayın.

Önce her alanı listeleyin ve basit bir dille tanımlayın. Hangi tür değeri kabul ettiği, zorunlu olup olmadığı, takip etmesi gereken format ve bağlı iş koşullarını not edin. "E-posta zorunludur" tek başına yeterli değildir; bir istemci hatalı formatı kabul ederken diğeri engelliyor olabilir.

Sonra önce backend kontrollerini uygulayın. Ardından web formunda ve mobil formda aynı kontrolleri yansıtın ki kullanıcılar gönderim öncesinde hızlı geri bildirim alsın.

Basit bir sıra iyi işler:

1. Alan alan kural listesini yazın.
2. Kuralları önce backend doğrulamasına koyun.
3. Web'de eşleşen ön uç kontrolleri ekleyin.
4. Mobilde aynı kontrolleri ekleyin.
5. Aynı örnek girdileri her yerde test edin.

Testler genellikle gizli farkların ortaya çıktığı yerdir. Her alan için küçük bir geçerli ve geçersiz örnek seti kullanın: boş değer, yanlış format, sınırın hemen altındaki değer, sınırdaki değer ve sınırın hemen üstündeki değer. Web ve mobil backend ile her durumda eşleşiyorsa güvenilir bir sisteme sahipsiniz demektir.

Örnek: müşteri kayıt formu

Bir kayıt formu bunu görmek için kolaydır. Formda üç alan olduğunu varsayalım: e-posta, şifre ve doğum tarihi.

Web ve mobilde form kullanıcı göndermeden önce aynı şekilde tepki vermelidir. E-posta boşsa her ikisi de durmalı ve aynı mesajı göstermelidir. Format yanlışsa her ikisi de bunu yakalamalıdır.

Şifre kuralı tam olarak eşleşmelidir. Minimum 8 karakterse her yerde 8 olmalı; webde 6, mobilde 10 gibi küçük uyumsuzluklar kullanıcıları hızla şaşırtır.

Doğum tarihi iş mantığının en çok sapabileceği yerdir. Ürününüz yalnızca 18 yaş ve üzerini kabul ediyorsa, her iki istemci de aynı kesme kuralını ve "bugün" tanımını kullanmalıdır. Aksi halde bir kullanıcı webde onaylanıp uygulamada reddedilebilir.

İstek sunulduğunda backend hâlâ her şeyi tekrar kontrol etmelidir. Çift hesapları, düzenlenmiş istekleri ve eski uygulama sürümlerinin gönderdiği güncel olmayan verileri orada yakalarsınız.

Mesajlar da açık ve tutarlı olmalıdır. İyi örnekler: "E-posta adresinizi girin", "Geçerli bir e-posta adresi girin", "Şifre en az 8 karakter olmalıdır" ve "Bu e-posta ile bir hesap zaten mevcut." Kullanıcılar aynı dili her yerde gördüğünde destek işleri kolaylaşır ve güven artar.

Uyumsuzluğa yol açan hatalar

Çoğu doğrulama problemi tek açık bir hatadan gelmez. Küçük uyumsuzluklar zaman içinde birikir.

Yaygın bir hata, bir kuralı yalnızca bir istemcide gizlemektir. iPhone uygulaması telefon numarasını zorunlu kılarken web uygulaması isteğe bağlı tutuyor olabilir. Başka bir hata aynı alan için farklı desenler kullanmaktır. Web formu posta kodunda boşluklara izin verirken Android engelliyor olabilir veya bir istemci telefon numarasındaki "+" işaretini kabul ederken diğeri kaldırıyor olabilir.

Daha ciddi bir sorun UI'ye fazla güvenmektir. İstemci tarafı doğrulama kullanıcıların hataları daha hızlı düzeltmesine yardımcı olur, ancak tek başına yeterli değildir. Eski uygulamalar, tarayıcı farklılıkları ve doğrudan API istekleri backend aynı iş kısıtlarını uygulamıyorsa kötü veri gönderebilir.

Zayıf hata mesajları her şeyi daha kötü hale getirir. "Geçersiz giriş" kullanıcının neyi düzeltmesi gerektiğini söylemez. Açık bir mesaj söyler. Eski uygulama sürümleri de kolayca gözden kaçan başka bir noktadır. Yeni bir sürüm zorunlu alan eklediyse, eski istemciler haftalarca eksik veri göndermeye devam edebilir.

Doğrulama sürüklenmeye devam ettiğinde yaygın nedenler basittir: gizli zorunlu alanlar, farklı format kuralları, zayıf backend kontrolleri, belirsiz hata mesajları ve eski sürümler için plan olmaması.

Yayın öncesi kontrolleriyle sorun yakalama

Göndermeden önce her istemcide aynı formu aynı şekilde test edin. Küçük bir örnek girdi seti kullanın ve bunları web uygulaması, mobil uygulama ve backend API üzerinden çalıştırın. Bir istemci bir değeri kabul edip diğeri reddediyorsa, paylaşılan doğrulama kurallarınız hâlâ gerçekten paylaşılıyor demektir.

Önce temel vakalarla başlayın. Zorunlu alanları boş bırakın, yanlış formatlar girin ve tam sınırdaki bir tarih, tek karakterli bir isim veya maksimum uzunlukta bir alan gibi kenar durumlarını deneyin.

Ön sürüm kontrolünüz birkaç doğrudan soruyu cevaplamalı: web ve mobil aynı kötü girdiyi reddediyor mu, backend istemcinin kaçırdığı hataları hâlâ reddediyor mu ve kullanıcılar her yerde hata mesajında aynı anlamı görüyor mu?

En çok önemli olan backend kontrolüdür. Biri UI'yi atlayıp eski bir uygulama kullanır veya veriyi doğrudan API'ye gönderirse sonuç hâlâ güvenli ve öngörülebilir olmalıdır.

Ayrıca hata metinlerini yan yana gözden geçirmek faydalıdır. Web uygulaması "Geçerli bir e-posta girin" derken mobil "Bilinmeyen hata" diyorsa insanlar uygulamaların farklı davrandığını düşünecektir.

Yayın sonrası birkaç gün destek taleplerini ve kullanıcı yorumlarını izleyin. "Telefonumda çalıştı ama masaüstünde çalışmadı" gibi şikayetler genellikle bir gösterge panosundan daha hızlı doğrulama boşluklarını işaret eder.

Daha temiz adımlar

Formlarınız web ve mobilde farklı şekillerde bozuluyorsa, hepsini bir anda düzeltmeye çalışmayın. En çok tekrar eden sorun yaratan formla başlayın; genellikle kayıt, ödeme veya profil düzenleme alanlarıdır.

Sıkı kuralları önce backend mantığına alın. Bu, zorunlu alanlar, format kontrolleri, tekrar kontrolleri ve yaş, hesap türü veya bölge gibi iş limitlerini kapsar. Sonra web ve mobilde bu kontrolleri hız ve netlik için yansıtın.

Kuralların yazımını açık tutun. "Müşteri durumunu doğrula" demek yerine "Ticari müşteriler vergi kimliği girmeli" ya da "SMS bildirimleri etkinse telefon numarası zorunludur" gibi yazın. Açık ifadeler tasarımcıların, geliştiricilerin, test edenlerin ve destek ekiplerinin sürüm öncesi boşlukları fark etmesini kolaylaştırır.

Tekrarlanan işi azaltmak istiyorsanız AppMaster yardımcı olabilir; çünkü backend, web ve native mobil uygulamaları tek sistemden oluşturmanıza izin verir. Bu, iş mantığını hizalı tutmayı kolaylaştırır ve her istemciye hızlı geri bildirim sağlar.

Hedef, bir gecede kusursuz formlar yapmak değil. Hedef daha az sürpriz, daha az destek bileti ve ürününüz büyürken web ile mobil doğrulamasının tutarlı kalmasıdır.