הוספת מבנה משנה לכתובת – דוגמאות (ארה"ב בלבד)

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

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

דוגמה נפוצה: הוספת מיקום משנה

בתרחיש הזה מוצגת כתובת שבה המערכת עשויה לבקש מהלקוח להוסיף מספר יחידה לכתובת.

הוזנה כתובת	אזור
‪1450 Brickell Avenue, Miami, FL 33131-4065	ארה"ב

הכרעה לגבי כתובת שחסר בה מידע על מיקום משני

בדוגמה הבאה מודגש האות החשוב.

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "possibleNextAction": "CONFIRM_ADD_SUBPREMISES"
}

פעולה: לגבי הכתובת הזו, כדאי להציע למשתמש להוסיף מספר יחידה.

דוגמה למקרה קצה: הוספת תת-מתחם

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

רכיבים משוערים ורכיבים שהוחלפו וחסרים במתחם

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

הוזנה כתובת	אזור
‪1450 Brickell Avenue, FL 33132-4065	ארה"ב

פסיקה לגבי רכיבים חסרים של מיקום משנה, רכיבים שהוסקו ורכיבים שהוחלפו

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "hasInferredComponents": true,
  "hasReplacedComponents": true,
  "possibleNextAction": "CONFIRM_ADD_SUBPREMISES"
}

בבדיקה נוספת של רכיבי הכתובת, מתברר שהיישוב הוסק והמיקוד הוחלף.

{
   "componentName": {
     "text": "33131",
   }
   "componentType": "postal_code",
   "confirmationLevel": "CONFIRMED",
   "replaced": true
},
{
   "componentName": {
     "text": "Miami",
     "languageCode": "en"
   }
   "componentType": "locality",
   "confirmationLevel": "CONFIRMED",
   "inferred": true
}

פעולה: לגבי הכתובת הזו, אפשר לבקש מהמשתמש להוסיף מספר יחידה או לבדוק את הכתובת כולה.