במסמך הזה מתואר תהליך היצירה של מערכת לבדיקת כתובות, לטפל במגוון תגובות מה-API לאימות כתובת. הוא כולל הסבר על לפתח לוגיקה להשתמש בצורה נכונה בתשובה, ולחקור אותות אחרים ומידע נוסף, ומתי ואיך לבקש מהלקוחות שלכם מידע נוסף.
באופן כללי תגובת ה-API קובעת את הדרכים הבאות שהמערכת לטפל בכתובת:
- תיקון – הכתובת באיכות נמוכה. עליך לבקש מידע נוסף.
- אישור – הכתובת באיכות גבוהה אבל משתנה מכתובת הקלט. יכול להיות שתתבקשו אישור.
- אישור – הכתובת באיכות גבוהה. אפשר מאשרים את הכתובת שצוינה.
מטרת המפתח
המסמך הזה יעזור לך לשנות את המערכת שלך כדי לנתח בצורה הטובה ביותר את התגובה מה-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.
הלוגיקה המדויקת תלויה במצב שלך – מידע נוסף זמין בהנחיות ההטמעה אפשר לקבל פרטים נוספים. אפשר גם להשתמש בהטמעה של הלוגיקה הזאת בקוד פתוח, שנמצא בספריית הרכיבים המורחבת.
סקירה כללית של תהליך העבודה
הטבלה הבאה מסכמת שתי פעולות שניתן לבצע במערכת:
- תהליך העבודה שצריך להשתמש בו בהתאם לאופן הפעולה, לאישור ולתיקון.
- האותות הראשונים שצריך לבדוק מהתשובה. האותות
שמתוארים כאן מגיעים מהנכס
verdict, והם לא היחידים אותות שצריך לבדוק, אבל מספקים אינדיקטור ראשוני לכתובת באיכות גבוהה. כל סוג התנהגות תואם לקטע במסמך הזה שמתאר סימנים נוספים שאולי יהיה צורך לחקור.
| התנהגות המערכת | |||
|---|---|---|---|
| תיקון הכתובת |
התשובה מ-
|
||
| אישור הכתובת |
התשובה מ-
|
||
| אישור הכתובת |
תגובת ה-API לאימות כתובת מציינת כתובת באיכות מצוינת.
|
||
הנחיות להטמעה
כשמתכננים את האופן שבו המערכת תגיב לאותות מה-API לאימות כתובות, תוכלו להיעזר בהמלצות הבאות כדי לשפר את התגובה מודל טרנספורמר. עם זאת, אלו רק המלצות, לכן חשוב לזכור צריך להתאים למודל העסקי שלכם.
| הנחיות | פרטים | |
|---|---|---|
| רמת סיכון |
צריך להביא בחשבון את הרמה של סבלנות כלפי המצב שלכם, כשאתם מביאים בחשבון בין הצעות לפעולה תיקונים ואישור הכתובת כפי שהוזנה. |
ה-API לאימות כתובת מחזיר מגוון אותות. שאפשר לשלב עם רמת הסיכון כדי לבצע אופטימיזציה לאימות תהליך האימות. לדוגמה, אם בכתובת יש מספר בית שלא אושר, אפשר עדיין לקבל אותה. לעומת זאת, אם הפעילות העסקית שלכם דורשת כתובות מדויקות יותר, עשויות לבקש מהמשתמש. לדוגמה, יכולות להשתייך לכל אחת מהקטגוריות האלה. ראו מספר רחוב שלא אושר מחוץ לארה"ב בקטע אישור כתובת – דוגמאות. |
| קבלת כתובות |
מומלץ לאפשר למערכת לקבל את הרשומה המקורית אם הלקוח לא מגיב להנחיות. |
במקרים כאלו, ייתכן שהלקוח הזין כתובת שאינה ב- במערכת, למשל עבור בנייה חדשה. |
| שליחת משוב |
כששולחים מחדש בקשה לאימות כתובת, אפשר:
לשלוח בקשה גם לנקודת הקצה (endpoint) |
כך Google תדע איך טיפלת בסוף התשובה הסופית. איך מטפלים בכתובות שעודכנו |
תיקון כתובת
תיקון כתובת כאשר התוצאות מציינות בבירור שהכתובת אינה של מודעות. לאחר מכן המערכת יכולה לבקש מהלקוח לספק את ולאחר מכן מנפיקים מחדש את תהליך העבודה כדי לקבל address.
תיקון אותות
ה-API לאימות כתובת מספק כמה אותות כדי להודיע לכם אם הכתובת צריכה להיות קבועה.
1. רמת הפירוט של האימות ורכיבים חסרים
שני האותות הבאים מספקים את הזיהוי הטוב ביותר לכתובת בעייתית:
- כשהשדה
validationGranularityהואOTHER, המערכת שלך לחקור את האותות לגבי רכיבי הכתובת כדי להבין איפה השגיאה ואיך לתקן אותה. - בכל פעם שהאובייקט
addressלאחר העיבוד מחזירmissingComponentTypes, המערכת צריכה לבדוק את הרכיב הזה. בנוסף, רכיבים חסרים מעבדים כתובת חלקית ולא ניתן למסור אותה.
2. אותות אחרים
ה-API לאימות כתובות מספק גם את האותות האחרים כדי לעזור לאבחן בעיות ספציפיות:
| רכיבים חשודים | כשרמת האישור של טיפוסים בני מנייה (enum) לרכיב היא
UNCOMFIRMED_AND_SUSPICIOUS, סביר להניח שהרכיב
שגוי.
|
|---|---|
| רכיב שלא נפתר | unresolvedToken הוא חלק מהקלט שאינו מזוהה כחלק חוקי של כתובת. |
3. אותות של כתובת בארה"ב
שדות מסוימים שרלוונטיים רק לכתובות בארה"ב מספקים אות שימושי לכך לא ניתן לשלוח את הכתובת וצריך לתקן אותה. עבור כתובת שדורשת אתם אמורים לראות את זה:
dpvConfirmation
|
N, D או ריק.
|
|---|
פרטים על dpvConfirmation זמינים במאמר
טיפול בכתובות בארצות הברית.
אישור כתובת
מאשרים כתובת כשבתוצאה מצוין שה-API לאימות כתובת הסיקה או ביצעה שינויים ברכיבי הכתובת כדי ליצור כתובת מאומתת. במקרים כאלה יש לכם כתובת למסירה, אבל אתם מעדיפים ברמת ודאות גבוהה יותר שהכתובת שתתקבל היא הכתובת שאליה התכוון לכל לקוח.
כדי לספק ללקוח את ההנחיות הנכונות, הלוגיקה שלכם תזהה
הרכיבים שמסומנים על ידי השירות כדי לקבוע איזו פעולה או לדווח על ה-API
שהוחל על הרכיב, למשל inferred, replaced או spellCorrected.
פרטים נוספים מופיעים בקטע AddressComponent בחומר העזר.
אישור האותות
ה-API לאימות כתובת מספק כמה אותות כדי להודיע לכם אם צריך לאשר את הכתובת.
1. רמת פירוט האימות
מקובל validationGranularity של ROUTE ומעלה, אבל
PREMISE או SUBPREMISE מספקות אות חזק יותר של מסירה.
2. אותות אחרים
כאשר מחליטים לאשר את הזנת הכתובת עם הלקוח, אנחנו גם מחליטים כדי לקבוע אילו רכיבים צריך לחקור:
| נתונים משוערים | כשהשדה hasInferredComponents הוא true,
אתה יודע שה-API מילא פרטים שהוא אספ מכתובת אחרת
רכיבים.
|
|---|---|
| הנתונים שהוחלפו | כשהשדה hasReplacedComponents הוא true, הערך
ה-API החליף נתונים שהוזנו בנתונים שהוא קבע שהכתובת תקינה.
|
3. אותות של כתובת בארה"ב
שדות מסוימים שרלוונטיים רק לכתובות בארה"ב מציינים שהלוגיקה שלכם מאשרים את הפרטים עם הלקוח. אחד מהתנאים הבאים מתקיימים:
dpvConfirmation
|
S
פרטים על |
|---|---|
| תגובה לבקשה | מכיל את השדה missingComponentType עם הערך של
subpremise.
|
אישור כתובת
אתם מקבלים כתובת אם מתקבלת החלטה לגבי מידת ודאות גבוהה ניתן למסור את הכתובת ואפשר להשתמש בה ללא אינטראקציה נוספת מצד הלקוח בתהליך במורד הזרם (downstream).
אישור האותות
ה-API לאימות כתובת מספק כמה אותות כדי להודיע לכם אם צריך לאשר את הכתובת.
1. רמת פירוט האימות
מקובל validationGranularity של PREMISE ומעלה, אבל בחלק מהמקרים
במקרים מסוימים, ROUTE עדיין מציין כתובת למסירה.
2. אותות אחרים
החלטה לגבי כתובת באיכות גבוהה צריכה לכלול גם את הפרטים הבאים:
- לא הוחלפו נתונים. במקרה הזה,
hasReplacedComponents: FALSE. - לא נגזרו רכיבים. במקרה הזה,
hasInferredComponents: FALSE.
3. אותות של כתובת בארה"ב
שדות מסוימים שרלוונטיים רק לכתובות בארה"ב מציינים כתובת באיכות גבוהה שאפשר לשלוח אליו. לכתובת קבילה בארה"ב, אמור להופיע הקוד הבאים:
dpvConfirmation
|
Y
פרטים על |
|---|