Ergebnis-Lebenszyklus
Ein Datenmodell für Telegram-Registrierungsergebnisse und Aktualisierungsversuche
Speichern Sie die Antwortfelder der Telegram-Registrierungsprüfung, trennen Sie abgeschlossene Ergebnisse von API-Fehlern und bewahren Sie einen lokalen Antwortzeitstempel.
Warum ein boolescher Wert nicht ausreicht
Ein Telegram-Registrierungsergebnis ist eine Beobachtung mit Zeitstempel, die aus einer abgeschlossenen Prüfung hervorgeht – keine dauerhafte Wahrheit, die an einer Telefonnummer hängt.
Ein Feld wie telegram_valid verliert wesentlichen Kontext. Es sagt nicht, welche normalisierte Nummer geprüft wurde, wann die Prüfung lief, ob false eine abgeschlossene Entscheidung war oder ob die Anfrage tatsächlich fehlgeschlagen ist. Die Datenbank sollte diese Unterschiede bewahren, damit eine Anwendung das Ergebnis ehrlich anzeigen und aktualisieren kann.
TG Validator liefert eine abgeschlossene Entscheidung synchron, das heißt, die Beobachtung kann geschrieben werden, sobald die HTTP-Antwort eintrifft. Die zurückgegebenen Felder sollten unverändert gespeichert werden, ohne einen weiteren Satz von Produktstatus zu erfinden.
Das Subjekt von seinen Beobachtungen trennen
Verwenden Sie einen stabilen internen Telefondatensatz und ordnen Sie ihm mehrere Prüfbeobachtungen zu. So wird die Historie nicht umgeschrieben, und eine spätere Aktualisierung bleibt leicht verständlich.
| Datensatz | Vorgeschlagene Felder | Zweck |
|---|---|---|
| Telefonquelle | phone_id, source_phone, source_system |
Bewahrt den ursprünglichen Geschäftsdatensatz |
| Normalisierte Telefonnummer | phone_id, e164_phone, normalized_at |
Hält den kanonischen Wert fest, der für Prüfungen verwendet wird |
| Prüfbeobachtung | phone_id, service_type, registered, received_at |
Speichert ein synchrones Ergebnis |
Ändert sich die Normalisierung, weil der ursprüngliche Länderkontext korrigiert wurde, legen Sie den kanonischen Datensatz neu an oder versionieren Sie ihn. Hängen Sie ein altes Telegram-Ergebnis nicht stillschweigend an eine neu interpretierte Telefonnummer.
Die exakt dokumentierten Antwortstrukturen verwenden
| Zurückgegebene Struktur | Wert von registered |
Bedeutung |
|---|---|---|
code=0, data.registered=true |
true | Die abgeschlossene Prüfung meldete registriert |
code=0, data.registered=false |
false | Die abgeschlossene Prüfung meldete nicht registriert |
API-code ungleich null |
Nicht vorhanden | Keine Registrierungsentscheidung; API-Fehler, kein Registrierungsergebnis |
Die Unterscheidung ist beabsichtigt. Ein API-Code ungleich null bedeutet, dass der Dienst keine boolesche Antwort zum Speichern hat. Ungültige Eingaben, Ablehnungen wegen Parallelität, unzureichendes Guthaben, Wartung und interne Fehler fügen data.registered keine weiteren Werte hinzu.
Aktuellen Zustand und letzten Versuch als zwei Sichten führen
Zwei Fragen sind häufig nützlich:
- Was ist die neueste abgeschlossene Registrierungsbeobachtung?
- Was ist beim neuesten Anfrageversuch passiert?
Sie können auf unterschiedliche Zeilen verweisen. Folgt auf ein abgeschlossenes Ergebnis true zum Zeitpunkt T1 ein API-Fehler zum Zeitpunkt T2, ist die neueste abgeschlossene Beobachtung weiterhin true zu T1, während ein separates Anfrageprotokoll den HTTP-Status und den API-Code von T2 festhalten kann. So verwechselt ein Operator T1 nicht mit einem frischen Ergebnis oder T2 mit false.
Wird ein späterer Aufruf zu T3 mit false abgeschlossen, rückt die Sicht auf den aktuellen abgeschlossenen Zustand auf T3 vor. Die Datensätze von T1 und T2 bleiben für Audits und Fehlersuche verfügbar.
Festlegen, wann eine Aktualisierung erforderlich ist
TG Validator liefert beim Aufruf eine aktuelle synchrone Beobachtung, doch die Aktualitätsrichtlinie liegt bei der integrierenden Anwendung. Wählen Sie ein maximal akzeptables Alter abhängig von der zu treffenden Entscheidung und machen Sie dieses Alter in der Oberfläche sichtbar.
Eine Aktualisierungsrichtlinie sollte festlegen:
- das maximal akzeptierte Alter für jeden Workflow;
- ob Operatoren nach einem späteren API-Fehler ein älteres abgeschlossenes Ergebnis verwenden dürfen;
- welche API-Antworten ungleich null später erneut übermittelt werden sollten;
- wie das Parallelitätslimit pro Nutzer die Planung beeinflusst;
- ob jeder Versuch oder nur abgeschlossene Beobachtungen langfristig aufbewahrt werden.
Wiederholen Sie ein abgeschlossenes registered=false nicht nur deshalb, weil es false ist. Wiederholen Sie die Prüfung, wenn eine neuere zeitpunktbezogene Beobachtung benötigt wird oder wenn der vorherige Versuch keine Entscheidung erbracht hat.
Eine präzise Abfrage des aktuellen Zustands
Die Abfrage des aktuellen Registrierungszustands sollte die neueste Beobachtung auswählen, bei der die äußere Antwort code=0 hatte, und dann ihren Wert registered zusammen mit dem lokalen received_at zurückgeben. Geben Sie den booleschen Wert niemals ohne seinen Zeitstempel zurück.
Die Abfrage des letzten Versuchs sollte die neueste Beobachtung mit beliebigem Status auswählen. Ist sie nicht abgeschlossen, kann die Oberfläche erklären, dass eine neuere Prüfung versucht wurde, ohne das letzte bekannte Registrierungsergebnis zu ersetzen.
Das dauerhafte Designprinzip
Hängen Sie Beobachtungen an, bewahren Sie ihre Zeitstempel und zwingen Sie betriebliche Unsicherheit niemals in einen Telegram-Registrierungswert.
Dieses Modell entspricht dem Produkt genau. TG Validator beantwortet synchron eine einzige Registrierungsfrage; es liefert keine Identitäts- oder Kontoprofildaten. Die Kundenanwendung stellt den stabilen Datensatz, die Aufbewahrungsrichtlinie, den Aktualisierungsplan und die Geschäftsentscheidung rund um jede Beobachtung bereit.