במסמך הזה מתוארים כמה תרחישים מהעולם האמיתי שבהם אותות התגובה מ-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
}