این سند تعدادی از سناریوهای دنیای واقعی را توصیف میکند که در آن Address Validation API سیگنالهای پاسخی را ارائه میدهد که رفتار اضافه کردن زیرمجموعه را از سیستم شما تضمین میکند. این سیگنال ها فقط برای آدرس های ایالات متحده در دسترس هستند. نمونه گردش کار را در Build your validation logic for context ببینید.
مثال متداول: اضافه کردن زیرمجموعه ها
این سناریو آدرسی را نشان می دهد که در آن سیستم شما ممکن است از مشتری بخواهد یک شماره واحد به آدرس اضافه کند.
آدرس وارد شد | منطقه |
---|---|
1450 Brickell Avenue, Miami, FL 33131-4065 | ایالات متحده |
حکم برای آدرسی که یک زیرمجموعه را از دست داده است
مثال زیر سیگنال مهم را برجسته می کند.
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"possibleNextAction": "CONFIRM_ADD_SUBPREMISES"
}
مثال Edge Case: 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
}