פיתוח לוגיקה לאימות

במסמך הזה מתואר תהליך ליצירת מערכת לבדיקת כתובות, שתדע לטפל במגוון תגובות מ-Address Validation API. המאמר כולל הסברים על בניית הלוגיקה לשימוש נכון בתשובה, על בדיקת אותות אחרים מה-API ועל המקרים שבהם כדאי לבקש מהלקוחות מידע נוסף ואיך לעשות זאת.

באופן כללי, התגובה של ה-API קובעת את הדרכים הבאות שבהן המערכת צריכה לטפל בכתובת:

• ‫handyman תיקון – הכתובת באיכות נמוכה. כדאי לבקש מידע נוסף.
• edit אישור – הכתובת באיכות גבוהה, אבל יש בה שינויים לעומת הכתובת שהוזנה. יכול להיות שתתבקשו לאשר את הפעולה.
• check אישור – הכתובת באיכות גבוהה. אפשר לאשר את הכתובת שצוינה.

המטרה העיקרית

המסמך הזה יעזור לכם לשנות את המערכת כדי לנתח בצורה הטובה ביותר את התגובה של ה-API ולקבוע את הפעולות הבאות שצריך לבצע עם הכתובות שסופקו. קטע הפסאודו-קוד הבא מדגים תהליך אפשרי.

if (the API response indicates significant problems in the address)
    FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
    CONFIRM - confirm with the user that the address is correct
else
    ACCEPT - continue with the address returned by the API.

הלוגיקה המדויקת תלויה במצב שלכם. מידע נוסף זמין בה��חיות להטמעה. אפשר גם להשתמש בהטמעה שלנו של הלוגיקה הזו בקוד פתוח, שנמצאת בספריית הרכיבים המורחבת.

סקירה כללית של תהליך העבודה

בטבלה הבאה מפורטות שתי פעולות שמתבצעות במערכת:

1. תהליך העבודה שצריך להשתמש בו בהתאם להתנהגות של התיקון, האישור והקבלה.
2. האותות הראשונים שצריך לבדוק בתגובה. האותות שמתוארים כאן מגיעים מנכס verdict והם לא האותות היחידים שצריך לבדוק, אבל הם מספקים אינדיקציה ראשונית לאיכות הכתובת. כל סוג התנהגות תואם לקטע במסמך הזה שמתאר אותות נוספים שכדאי לבדוק.

הדרכה בנושא הטמעה

כשמתכננים איך המערכת תגיב לאותות של אימות כתובות, ההמלצות הבאות יכולות לעזור לכם לבנות מודל תגובה יעיל יותר. עם זאת, אלה רק המלצות, ולכן חשוב לזכור שההטמעה צריכה להתאים למודל העסקי שלכם.

תיקון כתובת

תיקון כתובת כשהתוצאות מציינות בבירור שלא ניתן לשלוח לכתובת. ��אחר מכן, המערכת יכולה לבקש מהלקוח לספק את המידע הנדרש, ואז להפעיל מחדש את תהליך העבודה כדי לקבל כתובת למשלוח.

פתרון בעיות שקשורות לאותות

ממשק Address Validation API מספק מספר אותות שמאפשרים לדעת אם צריך לתקן כתובת.

1. גרנולריות של אימות ורכיבים חסרים

שני האותות האלה מספקים את האינדיקציה הטובה ביותר לכתובת בעייתית:

• בכל פעם שהשדה validationGranularity הוא OTHER, המערכת שלכם צריכה לבדוק את האותות של רכיבי הכתובת כדי לקבל מידע נוסף על המקום שבו השגיאה התרחשה ואיך לתקן אותה.
• בכל פעם שאובייקט address שעבר עיבוד חוזר מחזיר שדה missingComponentTypes, המערכת שלכם צריכה לבדוק את הרכיב הזה. רכיבים חסרים גם הופכים את הכתובת לחלקית וללא אפשרות למשלוח.

2. אותות אחרים

‫Address Validation API מספק גם את האותות האחרים כדי לעזור באבחון בעיות ספציפיות:

3. אותות של כתובות בארה"ב

שדות מסוימים שרלוונטיים רק לכתובות בארה"ב מספקים אות שימושי לכך שהכתובת לא ניתנת למשלוח וצריך לתקן אותה. אם יש כתובת שצריך לתקן, אתם אמורים לראות את ההודעה הבאה:

פרטים על dpvConfirmation מופיעים במאמר בנושא טיפול בכתובות בארצות הברית.

דוגמאות לתיקון כתובות

אישור כתובת

כתובת מאומתת אם פסק הדין מציין שממשק Address Validation API הסיק או ביצע שינויים ברכיבי הכתובת כדי ליצור כתובת מאומתת. במקרים כאלה, יש לכם כתובת שאפשר לשלוח אליה, אבל אתם רוצים להיות בטוחים יותר שהכתובת שמתקבלת היא הכתובת שהלקוח התכוון אליה.

כדי לספק ללקוח הנחיה נכונה, הלוגיקה שלכם תזהה את הרכיבים שסומנו על ידי השירות כדי לקבוע איזו פעולה או דגל ה-API החיל על הרכיב, כמו inferred, replaced או spellCorrected. פרטים נוספים מופיעים ב-AddressComponent במאמר ��נושא הפניה.

אותות אישור

ממשק Address Validation API מספק מספר אותות שמאפשרים לדעת אם צריך לאשר כתובת.

1. רמת הפירוט של האימות

דירוג של validationGranularity מתוך ROUTE ומעלה הוא קביל, אבל דירוג של PREMISE או SUBPREMISE מספק אות חזק יותר של יכולת מסירה.

2. אותות אחרים

כשמחליטים לאשר את הזנת הכתובת עם הלקוח, פסק הדין מספק גם את הפרטים הבאים כדי לקבוע אילו רכיבים צריך לבדוק:

3. אותות של כתובות בארה"ב

בשדות מסוימים שרלוונטיים רק לכתובות בארה"ב מצוין שהלוגיקה שלכם צריכה לאשר את הפרטים מול הלקוח. אחת מהאפשרויות הבאות רלוונטית:

דוגמאות לכתובות לאישור

אישור כתובת

אתם מקבלים כתובת כשההחלטה מספקת רמת ודאות גבוהה לכך שהכתובת ניתנת למסירה ושאפשר להשתמש בה בלי אינטראקציה נוספת עם הלקוח בתהליך בהמשך.

קבלת אותות

ממשק Address Validation API מספק מספר אותות שמאפשרים לדעת אם צריך לאשר כתובת.

1. רמת הפירוט של האימות

דירוג של validationGranularity או יותר הוא קביל, אבל במקרים מסוימים, גם דירוג של ROUTE מציין כתובת שאפשר לשלוח אליה.PREMISE

2. אותות אחרים

בנוסף, פסק דין לגבי כתובת באיכות גבוהה צריך לכלול גם את הפרטים הבאים:

• אין נתונים שהוחלפו. במקרה הזה, hasReplacedComponents: FALSE.
• לא זוהו רכיבים משוערים. במקרה הזה, hasInferredComponents: FALSE.

3. אותות של כתובות בארה"ב

שדות מסוימים שרלוונטיים רק לכתובות בארה"ב מציינים כתובת באיכות גבוהה שאפשר לשלוח אליה. אם הכתובת בארה"ב תקינה, יופיעו הפרטים הבאים:

דוגמאות לכתובות