Telegram kayıt sonuçları ve yenileme denemeleri için bir veri modeli

Tek bir boolean neden yeterli değildir

Bir Telegram kayıt sonucu, bir telefon numarasına iliştirilmiş kalıcı bir gerçek değil, tamamlanmış bir kontrolün ürettiği zaman damgalı bir gözlemdir.

telegram_valid gibi bir alan temel bağlamı kaybeder. Hangi normalleştirilmiş numaranın kontrol edildiğini, kontrolün ne zaman çalıştığını, false değerinin tamamlanmış bir karar olup olmadığını veya isteğin aslında başarısız olup olmadığını söylemez. Veritabanı bu ayrımları korumalıdır ki bir uygulama sonucu dürüstçe gösterebilsin ve yenileyebilsin.

TG Validator tamamlanmış bir kararı senkron olarak döndürür; bu da gözlemin HTTP yanıtı gelir gelmez yazılabileceği anlamına gelir. Döndürülen alanlar, başka bir ürün durumu kümesi icat edilmeden olduğu gibi saklanmalıdır.

Konuyu gözlemlerinden ayırın

Sabit tek bir dahili telefon kaydı kullanın ve ona birden fazla kontrol gözlemi bağlayın. Bu, geçmişin yeniden yazılmasını önler ve sonraki bir yenilemenin anlaşılmasını kolaylaştırır.

Orijinal ülke bağlamı düzeltildiği için normalleştirme değişirse kanonik kaydı yeniden oluşturun veya sürümlendirin. Eski bir Telegram sonucunu yeniden yorumlanmış bir telefon numarasına sessizce bağlamayın.

Belgelenmiş yanıt yapılarını tam olarak kullanın

Bu ayrım bilinçlidir. Sıfır olmayan bir API kodu, hizmetin saklanacak bir boolean yanıtı olmadığı anlamına gelir. Geçersiz girdi, eşzamanlılık retleri, yetersiz bakiye, bakım ve dahili hatalar data.registered alanına yeni değerler eklemez.

Güncel durumu ve son denemeyi iki ayrı görünüm olarak tutun

Çoğu zaman iki soru faydalıdır:

1. En yeni tamamlanmış kayıt gözlemi nedir?
2. En yeni istek denemesinde ne oldu?

Bu sorular farklı satırları gösterebilir. T1 anındaki tamamlanmış bir true sonucunu T2 anında bir API hatası izlerse en yeni tamamlanmış gözlem hâlâ T1 anındaki true değeridir; ayrı bir istek günlüğü ise T2'ye ait HTTP durumunu ve API kodunu kaydedebilir. Bu, bir operatörün T1'i taze bir sonuç veya T2'yi false sanmasını önler.

Daha sonraki bir çağrı T3 anında false olarak tamamlandığında güncel tamamlanmış görünüm T3'e ilerler. T1 ve T2 kayıtları denetim ve sorun giderme için erişilebilir kalır.

Yenilemenin ne zaman gerektiğini tanımlayın

TG Validator çağrıldığında güncel ve senkron bir gözlem sağlar, ancak tazelik politikası entegre eden uygulamaya aittir. Verilen karara göre kabul edilebilir azami bir yaş seçin ve ardından bu yaşı arayüzde görünür kılın.

Bir yenileme politikası şunları belirtmelidir:

• her iş akışı için kabul edilen azami yaş;
• sonraki bir API hatasından sonra operatörlerin daha eski bir tamamlanmış sonucu kullanıp kullanamayacağı;
• hangi sıfır olmayan API yanıtlarının daha sonra yeniden gönderilmesi gerektiği;
• kullanıcı başına eşzamanlılık sınırının zamanlamayı nasıl şekillendirdiği;
• uzun vadede her denemenin mi yoksa yalnızca tamamlanmış gözlemlerin mi saklanacağı.

Tamamlanmış bir registered=false sonucunu yalnızca false olduğu için yeniden denemeyin. Daha yeni, belirli bir ana ait bir gözleme ihtiyaç duyulduğunda veya önceki deneme karar üretmediğinde yeniden deneyin.

Kesin bir güncel durum sorgusu

Güncel kayıt durumu, dış yanıtın code=0 olduğu en son gözlemi seçmeli, ardından bu gözlemin registered değerini ve yerel received_at değerini birlikte döndürmelidir. Boolean değeri asla zaman damgası olmadan döndürmeyin.

Son deneme durumu ise herhangi bir statüdeki en yeni gözlemi seçmelidir. Bu gözlem tamamlanmamışsa arayüz, bilinen son kayıt sonucunu değiştirmeden daha yeni bir kontrolün denendiğini açıklayabilir.

Kalıcı tasarım ilkesi

Gözlemleri ekleyin, zaman damgalarını koruyun ve operasyonel belirsizliği asla bir Telegram kayıt değerine zorlamayın.

Bu model ürünle tam olarak örtüşür. TG Validator tek bir kayıt sorusunu senkron olarak yanıtlar; kimlik veya hesap profili verisi sağlamaz. Müşteri uygulaması ise her gözlemin etrafındaki sabit kaydı, saklama politikasını, yenileme takvimini ve iş kararını sağlar.