ساختن منطق اعتبارسنجی

این سند فرایند ساختن سیستم بررسی نشانی را برای مدیریت کردن انواع پاسخ‌های Address Validation API شرح می‌دهد. این بخش نحوه ساختن منطق برای استفاده صحیح از پاسخ، بررسی کردن سایر نشان‌های میانای برنامه‌سازی کاربردی، و زمان و نحوه درخواست اطلاعات بیشتر از مشتریان را پوشش می‌دهد.

به‌طور کلی، پاسخ میانای برنامه‌سازی کاربردی تعیین می‌کند که سیستم شما چگونه باید نشانی را مدیریت کند:

• handyman اصلاح کنید—کیفیت نشانی پایین است. باید اطلاعات بیشتری درخواست کنید.
• edit تأیید—نشانی کیفیت بالایی دارد، اما تغییراتی نسبت به نشانی ورودی دارد. ممکن است از شما خواسته شود تأیید کنید.
• check پذیرفتن—نشانی کیفیت بالایی دارد. می‌توانید نشانی ارائه‌شده را بپذیرید.

هدف کلیدی

این سند به شما کمک می‌کند سیستم خود را برای تجزیه‌وتحلیل بهتر پاسخ میانای برنامه‌سازی کاربردی و تعیین اقدامات بعدی با نشانی‌های ارائه‌شده اصلاح کنید. شبه‌کد زیر جریان احتمالی را نشان می‌دهد.

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 تعدادی سیگنال ارائه می‌دهد تا به شما اطلاع دهد که آیا نشانی باید اصلاح شود یا نه.

۱. دقت اعتبارسنجی و قطعات مفقود

این دو سیگنال بهترین نشانگر نشانی مشکل‌دار هستند:

• هرگاه فیلد validationGranularity OTHER باشد، سیستم شما باید سیگنال‌های مؤلفه نشانی را بررسی کند تا درباره محل وقوع خطا و نحوه رفع آن اطلاعات بیشتری کسب کند.
• هرگاه شیء address پس‌پردازش‌شده فیلد missingComponentTypes را برگرداند، سیستم شما باید آن مؤلفه را بررسی کند. نبودن بخش‌هایی از نشانی نیز باعث می‌شود نشانی ناقص و غیرقابل‌تحویل شود.

۲. نشان‌های دیگر

Address Validation API سیگنال‌های دیگری نیز برای کمک به تشخیص مشکلات خاص ارائه می‌دهد:

۳. سیگنال‌های نشانی ایالات متحده

برخی فیلدها که فقط برای نشانی‌های ایالات متحده کاربرد دارند، سیگنال مفیدی ارائه می‌دهند که نشانی قابل‌تحویل نیست و باید اصلاح شود. برای نشانی‌ای که نیاز به اصلاح دارد، باید موارد زیر را ببینید:

برای جزئیات درباره dpvConfirmation، رسیدگی به نشانی‌های ایالات متحده را ببینید.

نمونه‌های اصلاح نشانی

تأیید نشانی

وقتی رأی نشان می‌دهد که Address Validation API برای تولید نشانی معتبرشده، اجزای نشانی را استنباط کرده یا تغییر داده است، نشانی را تأیید می‌کنید. در این موارد، نشانی قابل‌تحویل دارید، اما ترجیح می‌دهید اطمینان بیشتری داشته باشید که نشانی حاصل همان نشانی مدنظر مشتری است.

برای ارائه پیام‌واره صحیح به مشتری، منطق شما مؤلفه‌های پرچم‌گذاری‌شده توسط سرویس را شناسایی می‌کند تا تعیین کند میانای برنامه‌سازی کاربردی کدام کنش یا پرچم را برای مؤلفه اعمال کرده است، مثلاً inferred، replaced، یا spellCorrected. AddressComponent را در مرجع ببینید.

تأیید نشان‌ها

Address Validation API تعدادی سیگنال ارائه می‌دهد تا به شما اطلاع دهد که آیا نشانی باید تأیید شود یا نه.

۱. دقت اعتبارسنجی

validationGranularity ROUTE یا بهتر قابل‌قبول است، اما PREMISE یا SUBPREMISE سیگنال قوی‌تری از قابلیت تحویل ارائه می‌دهد.

۲. نشان‌های دیگر

هنگام تصمیم‌گیری برای تأیید ورودی نشانی با مشتری، حکم همچنین موارد زیر را برای تعیین اینکه کدام مؤلفه‌ها باید بررسی شوند ارائه می‌دهد:

۳. سیگنال‌های نشانی ایالات متحده

برخی‌از فیلدها که فقط برای نشانی‌های ایالات متحده کاربرد دارند نشان می‌دهند که منطق شما باید جزئیات را با مشتری تأیید کند. یکی از موارد زیر صدق کند:

نمونه‌های تأیید نشانی

پذیرفتن نشانی

وقتی رأی با درجه اطمینان بالایی نشان دهد که نشانی قابل‌تحویل است و می‌توان از آن بدون تعامل بیشتر مشتری در فرایند پایین‌دستی استفاده کرد، نشانی را می‌پذیرید.

پذیرفتن نشان‌ها

Address Validation API تعدادی سیگنال ارائه می‌دهد تا به شما اطلاع دهد که آیا نشانی باید تأیید شود یا نه.

۱. دقت اعتبارسنجی

validationGranularity PREMISE یا بهتر قابل‌قبول است، اما در برخی موارد، ROUTE همچنان نشان‌دهنده نشانی قابل‌تحویل است.

۲. نشان‌های دیگر

رأی برای نشانی با کیفیت بالا باید موارد زیر را نیز ارائه دهد:

• داده‌ای جایگزین نشده است. در این مورد، hasReplacedComponents: FALSE.
• عناصر استنباط‌شده وجود ندارد. در این صورت، hasInferredComponents: FALSE.

۳. سیگنال‌های نشانی ایالات متحده

برخی‌از فیلدها که فقط برای نشانی‌های ایالات متحده کاربرد دارند نشان‌دهنده نشانی با کیفیت بالا هستند که می‌توان به آن ارسال کرد. برای نشانی قابل‌قبول در ایالات متحده، باید موارد زیر را ببینید:

نمونه‌های نشانی قابل‌قبول