पुष्टि करने वाला लॉजिक बनाएं

इस दस्तावेज़ में, पते की पुष्टि करने वाले एपीआई से मिलने वाले अलग-अलग जवाबों को मैनेज करने के लिए, पते की जांच करने वाला सिस्टम बनाने की प्रोसेस के बारे में बताया गया है. इसमें, एपीआई के जवाब को समझने का तरीका बताया गया है. इससे यह तय करने में मदद मिलती है कि ग्राहकों से ज़्यादा जानकारी कब और कैसे मांगी जाए.

आम तौर पर, एपीआई रिस्पॉन्स से यह तय होता है कि आपके सिस्टम को किसी पते को कैसे मैनेज करना चाहिए:

  • ठीक करें—पते में गंभीर समस्याएं हो सकती हैं.
    अपने ग्राहक से ज़्यादा जानकारी पाने के लिए कहें.
  • सब-प्राइमिस जोड़ें—ऐसा हो सकता है कि पते में सब-प्राइमिस की जानकारी मौजूद न हो.
    अपने ग्राहक से यूनिट नंबर जोड़ने के लिए कहें.
  • पुष्टि करें—पते में छोटी-मोटी समस्याएं हो सकती हैं.
    अपने ग्राहक से, पते की पुष्टि करने के लिए कहें.
  • स्वीकार करें—ऐसा हो सकता है कि पते में कोई समस्या न हो.
    अगर आपको अपने जोखिम पर, बिना किसी और अनुरोध के ईमेल पते का इस्तेमाल करना है, तो ऐसा करें.

मुख्य मकसद

इस दस्तावेज़ की मदद से, एपीआई के रिस्पॉन्स का बेहतर तरीके से विश्लेषण करने के लिए अपने सिस्टम में बदलाव किया जा सकता है. साथ ही, दिए गए पतों के लिए आगे की कार्रवाइयां तय की जा सकती हैं. यहां दिए गए आभासी कोड में, संभावित फ़्लो दिखाया गया है.

if (verdict.possibleNextAction == FIX)
    Prompt the user to fix the address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
    Prompt the user to add a unit number.
else if (verdict.possibleNextAction == CONFIRM)
    Confirm with the user that the address is correct.
else
    Continue with the address returned by the API.

सही लॉजिक आपकी स्थिति पर निर्भर करता है - ज़्यादा जानकारी के लिए, पुष्टि करने के लॉजिक को पसंद के मुताबिक बनाएं देखें.

वर्कफ़्लो के उदाहरण

नीचे दी गई टेबल में, ऐसे वर्कफ़्लो के उदाहरण दिए गए हैं जिन्हें एपीआई के रिस्पॉन्स के आधार पर, अपने ग्राहक को सूचना देने के लिए लागू किया जा सकता है.

आपके सिस्टम का व्यवहार
पता ठीक करना

verdict से मिले जवाब से पता चलता है कि पते में कोई बड़ी समस्या हो सकती है. उदाहरण के लिए, verdict.possibleNextAction, FIX है. अपने ग्राहक से ज़्यादा जानकारी पाने के लिए कहें.

वर्कफ़्लो

  1. अगर ज़रूरी हो, तो पते के कॉम्पोनेंट की जांच करें.
  2. ग्राहक को पते से जुड़ी समस्याएं ठीक करने के लिए कहें.
  3. अपडेट किए गए पते की पुष्टि का अनुरोध करें.
  4. (ज़रूरी नहीं) एपीआई के लिए, सुझाव/राय/शिकायत वाले एंडपॉइंट पर अनुरोध भेजें. अपडेट किए गए पते मैनेज करना लेख पढ़ें.
  5. पता डालें.
उप-प्राइमिस जोड़ें

verdict से मिले जवाब से पता चलता है कि पते में सब-प्राइमिस मौजूद नहीं है. उदाहरण के लिए, verdict.possibleNextAction का मतलब CONFIRM_ADD_SUBPREMISES है. अपने ग्राहक से यूनिट नंबर जोड़ने के लिए कहें.

वर्कफ़्लो

  1. ग्राहक से यूनिट नंबर जोड़ने के लिए कहें.
  2. अपडेट किए गए पते की पुष्टि का अनुरोध करें.
  3. (ज़रूरी नहीं) एपीआई के लिए, सुझाव/राय/शिकायत वाले एंडपॉइंट पर अनुरोध भेजें. अपडेट किए गए पते मैनेज करना लेख पढ़ें.
  4. पता डालें.
पते की पुष्टि करना

verdict से मिले जवाब से पता चलता है कि पते में कुछ छोटी-मोटी समस्याएं हो सकती हैं. उदाहरण के लिए, verdict.possibleNextAction का मतलब CONFIRM है. अपने खरीदार को पते की समीक्षा करने के लिए कहें.

वर्कफ़्लो

  1. इनमें सुधार करना ज़रूरी है:
    1. अगर ज़रूरी हो, तो पते के कॉम्पोनेंट की जांच करें.
    2. अपडेट किए गए पते की पुष्टि का अनुरोध करें.
    3. (ज़रूरी नहीं) एपीआई के लिए, सुझाव/राय/शिकायत वाले एंडपॉइंट पर अनुरोध भेजें. अपडेट किए गए पते मैनेज करना लेख पढ़ें.
    4. पता डालें.
  2. कोई बदलाव करने की ज़रूरत नहीं है:
    1. (ज़रूरी नहीं) एपीआई के लिए, सुझाव/राय/शिकायत वाले एंडपॉइंट पर अनुरोध भेजें. अपडेट किए गए पते मैनेज करना लेख पढ़ें.
    2. पता डालें.
पता स्वीकार करें

verdict से मिले जवाब से पता चलता है कि पते में कोई समस्या नहीं हो सकती. उदाहरण के लिए, verdict.possibleNextAction का मतलब ACCEPT है. खतरे के लेवल के हिसाब से, उस पते का इस्तेमाल करें जिसका इस्तेमाल आपने

वर्कफ़्लो

सामान लौटाने का पता डालें.

पुष्टि करने का लॉजिक पसंद के मुताबिक बनाना

verdict.possibleNextAction फ़ील्ड के नतीजों का इस्तेमाल करके यह तय किया जा सकता है कि आपका सिस्टम, एपीआई रिस्पॉन्स के साथ कैसे आगे बढ़ेगा. हालांकि, कारोबार की खास ज़रूरतों को पूरा करने के लिए, कस्टम लॉजिक बनाने पर भी विचार किया जा सकता है.

इस सेक्शन का मकसद यह बताना है कि एपीआई के रिस्पॉन्स को समझने के लिए, अपना कस्टम लॉजिक कैसे बनाया जा सकता है. इससे यह तय किया जा सकता है कि आपको अपने ग्राहक से अनुरोध करना है या नहीं और अगर करना है, तो कैसे करना है. इस सेक्शन में, जोखिम के लेवल और एपीआई के रिस्पॉन्स के अन्य सिग्नल शामिल हैं. इनका इस्तेमाल करके, अपने हिसाब से बदलाव किए जा सकते हैं.

हालांकि, अगर आपने आगे के कदमों के लिए सिर्फ़ verdict.possibleNextAction पर भरोसा किया है, तो भी नीचे दिए गए अन्य सिग्नल की मदद से, पते से जुड़ी संभावित समस्याओं के बारे में जानकारी हासिल की जा सकती है.

जोखिम को स्वीकार करने की क्षमता

यह डिज़ाइन करते समय कि आपका सिस्टम, पते की पुष्टि करने वाले एपीआई के सिग्नल का जवाब कैसे देगा, इन सुझावों से आपको जवाब देने का ज़्यादा असरदार मॉडल बनाने में मदद मिल सकती है. हालांकि, ये सिर्फ़ सुझाव हैं. इसलिए, ध्यान रखें कि आपके लागू करने का तरीका आपके कारोबार के मॉडल के हिसाब से हो.

सलाह जानकारी
जोखिम का स्तर

सुधार करने के लिए कहा जाए या डाले गए पते को स्वीकार किया जाए, इस फ़ैसले को लेते समय अपनी स्थिति के हिसाब से, गड़बड़ी की सीमा को ध्यान में रखें.

पते की पुष्टि करने वाला एपीआई, कई तरह के सिग्नल दिखाता है. इन सिग्नल को जोड़कर, पुष्टि करने की प्रोसेस को ऑप्टिमाइज़ किया जा सकता है.

उदाहरण के लिए, अगर किसी पते में सड़क का वह नंबर दिया गया है जिसकी पुष्टि नहीं हुई है, तो भी आपके पास उसे स्वीकार करने का विकल्प होता है. दूसरी ओर, अगर आपके कारोबार के लिए, पते की ज़्यादा सटीक जानकारी की ज़रूरत है, तो उपयोगकर्ता से इसकी जानकारी मांगी जा सकती है. किसी ऐसे उदाहरण के लिए जो दोनों कैटगरी में आ सकता है, पता स्वीकार करें - उदाहरण में अमेरिका से बाहर का वह सड़क नंबर जिसकी पुष्टि नहीं हुई है देखें.

पते स्वीकार करना

अगर ग्राहक प्रॉम्प्ट का जवाब नहीं देता है, तो अपने सिस्टम को मूल एंट्री स्वीकार करने की अनुमति देना एक अच्छा तरीका है.

इन मामलों में, हो सकता है कि ग्राहक ने ऐसा पता डाला हो जो सिस्टम में मौजूद न हो. जैसे, नए निर्माण के लिए.

जोखिम से बचने के लिए चेकआउट फ़्लो का उदाहरण

अगर आपको डिलीवरी न होने के जोखिम को कम करना है, तो अपने ग्राहकों को ज़्यादा बार प्रॉम्प्ट करने के लिए, लॉजिक को पसंद के मुताबिक बनाया जा सकता है. उदाहरण के लिए, मुख्य मकसद सेक्शन में बताए गए लॉजिक का इस्तेमाल करने के बजाय, इस लॉजिक का इस्तेमाल किया जा सकता है.

if (verdict.possibleNextAction == FIX or verdict.validationGranularity
== OTHER or verdict.validationGranularity == ROUTE)
  Prompt customer to fix their address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
  Prompt customer to add a unit number.
else if (verdict.possibleNextAction == CONFIRM or verdict.validationGranularity
== PREMISE_PROXIMITY or verdict.hasSpellCorrectedComponents or
verdict.hasReplacedComponents or verdict.hasInferredComponents)
  Prompt customer to confirm their address.
else
  Proceed with the returned address.

आसान चेकआउट फ़्लो का उदाहरण

अगर आपको चेकआउट फ़्लो में आने वाली समस्याओं को कम करना है, तो अपने लॉजिक को पसंद के मुताबिक बनाएं, ताकि ग्राहकों को कम बार सूचनाएं भेजी जा सकें. उदाहरण के लिए, मुख्य मकसद सेक्शन में बताए गए लॉजिक का इस्तेमाल करने के बजाय, इस लॉजिक का इस्तेमाल किया जा सकता है.

if (verdict.possibleNextAction == FIX)
  Prompt customer to fix their address.
else if (verdict.hasReplacedComponents)
  Prompt customer to confirm their address.
else
  Proceed with the returned address.

FIX सिग्नल

जब नतीजों से साफ़ तौर पर पता चलता हो कि पते पर डिलीवरी नहीं की जा सकती, तो पते में बदलाव करें. इसके बाद, आपका सिस्टम खरीदार से ज़रूरी जानकारी मांग सकता है. इसके बाद, डिलीवरी के लिए पता पाने के लिए, आपको अपना वर्कफ़्लो फिर से जारी करना होगा.

Address Validation API के रिस्पॉन्स में मौजूद इन फ़ील्ड का इस्तेमाल, verdict.possibleNextAction के साथ-साथ किया जा सकता है. इससे यह पता चलता है कि पते में कोई बड़ी समस्या है या नहीं और अगर है, तो वह क्या है.

पुष्टि के लिए ज़रूरी जानकारी जब किसी पते के लिए पुष्टि करने की बारीकी से जानकारी देने वाला एनम OTHER हो, तो हो सकता है कि पता गलत हो.
कॉम्पोनेंट मौजूद नहीं हैं अगर address.missingComponentTypes खाली नहीं है, तो हो सकता है कि पते में ज़रूरी जानकारी मौजूद न हो.
संदिग्ध कॉम्पोनेंट जब किसी कॉम्पोनेंट के लिए पुष्टि करने के लेवल का एनम UNCONFIRMED_AND_SUSPICIOUS होता है, तो हो सकता है कि कॉम्पोनेंट गलत हो.
समस्या वाले कॉम्पोनेंट unresolvedToken, डाले गए पते का ऐसा हिस्सा होता है जिसे पते के मान्य हिस्से के तौर पर नहीं पहचाना जाता.
USPS डीपीवी की पुष्टि अगर uspsData.dpvConfirmation N है या खाली है, तो हो सकता है कि पते में कोई समस्या हो. यह फ़ील्ड सिर्फ़ अमेरिका के पतों के लिए उपलब्ध है. uspsData.dpvConfirmation के बारे में ज़्यादा जानकारी के लिए, अमेरिका के पतों को मैनेज करना लेख पढ़ें.

पते के उदाहरण ठीक करना

CONFIRM_ADD_SUBPREMISES सिग्नल (सिर्फ़ अमेरिका के पतों के लिए)

जब पता की पुष्टि करने वाले एपीआई के जवाब से पता चलता है कि पते में सब-प्राइमिस मौजूद नहीं है, तो अपने ग्राहक से पते की समीक्षा करने के लिए कहें और यूनिट नंबर जोड़ने के बारे में सोचें. इन मामलों में, हो सकता है कि बिल्डिंग का पता मान्य हो, लेकिन आपको इस बात का ज़्यादा भरोसा चाहिए कि नतीजे में मिला पता वही है जो खरीदार ने दिया है.

पते की पुष्टि करने वाले एपीआई के रिस्पॉन्स के इन फ़ील्ड का इस्तेमाल, verdict.possibleNextAction के साथ-साथ किया जा सकता है. इससे यह पता चलता है कि पते में सब-प्राइमिस मौजूद है या नहीं.

Missing subpremise component जब address.missingComponentTypes फ़ील्ड में subpremise की वैल्यू होती है, तो इसका मतलब है कि पते में यूनिट नंबर मौजूद नहीं है.
USPS डीपीवी की पुष्टि अगर uspsData.dpvConfirmation S है, तो इसका मतलब है कि पते का प्राइमरी नंबर, USPS के डेटाबेस में मौजूद किसी पते से मैच हो गया है. हालांकि, पते में दूसरा नंबर भी होना चाहिए. यह फ़ील्ड सिर्फ़ अमेरिका के पतों के लिए उपलब्ध है. uspsData.dpvConfirmation के बारे में ज़्यादा जानकारी के लिए, अमेरिका के पतों को मैनेज करना लेख पढ़ें.

उप-प्राइमिस के पते के उदाहरण जोड़ना

पुष्टि करने वाले सिग्नल

किसी पते की पुष्टि तब की जाती है, जब नतीजे से पता चलता है कि पते की पुष्टि करने वाला एपीआई, पुष्टि किए गए पते को दिखाने के लिए, पते के कॉम्पोनेंट में अनुमान लगाता है या बदलाव करता है. इन मामलों में, आपके पास डिलीवर किया जा सकने वाला पता होता है. हालांकि, आपको यह पक्का करना होता है कि पता सही है और खरीदार ने यही पता दिया है.

पता की पुष्टि करने वाले एपीआई के रिस्पॉन्स में मौजूद इन फ़ील्ड का इस्तेमाल, verdict.possibleNextAction के साथ-साथ किया जा सकता है. इससे यह पता चलता है कि पते में छोटी-मोटी समस्याएं हैं या नहीं और वे समस्याएं क्या हैं.

पुष्टि के लिए ज़रूरी जानकारी अगर किसी पते के लिए validationGranularity, ROUTE या PREMISE_PROXIMITY है, तो हो सकता है कि पता गलत हो.
अनुमानित डेटा जब hasInferredComponents फ़ील्ड true होता है, तो इसका मतलब है कि एपीआई ने पते के दूसरे कॉम्पोनेंट से मिली जानकारी को भर दिया है.
बदला गया डेटा जब hasReplacedComponents फ़ील्ड true है, तो एपीआई ने डाले गए डेटा को उस डेटा से बदल दिया जो पते को मान्य बनाने के लिए ज़रूरी था.
वर्तनी में सुधार जब hasSpellCorrectedComponents फ़ील्ड true है, तो एपीआई ने गलत स्पेलिंग वाले कुछ कॉम्पोनेंट की स्पेलिंग ठीक कर दी.

पते के उदाहरणों की पुष्टि करना

ACCEPT सिग्नल

Address Validation API के एपीआई रिस्पॉन्स से यह पता चलने पर कि पते की पुष्टि हो गई है और वह डिलीवर किया जा सकता है, तो उस पते को स्वीकार किया जा सकता है. साथ ही, इस पते का इस्तेमाल, ग्राहक से बातचीत किए बिना भी किया जा सकता है.

Address Validation API के रिस्पॉन्स में मौजूद इन फ़ील्ड का इस्तेमाल, verdict.possibleNextAction के साथ-साथ किया जा सकता है. इससे यह पता चलता है कि कोई पता सही है या नहीं.

पुष्टि के लिए ज़रूरी जानकारी validationGranularity के तौर पर PREMISE को अक्सर स्वीकार किया जाता है. हालांकि, ROUTE की वैल्यू से भी डिलीवरी के लिए सही पते का पता चल सकता है.
अनुमानित डेटा नहीं जब hasInferredComponents फ़ील्ड false होता है, तो इसका मतलब है कि आउटपुट में कोई कॉम्पोनेंट नहीं मिला.
बदला गया डेटा मौजूद नहीं है जब hasReplacedComponents फ़ील्ड false होता है, तो इसका मतलब है कि किसी भी इनपुट डेटा को बदला नहीं गया है.
वर्तनी में सुधार नहीं किए गए जब hasSpellCorrectedComponents फ़ील्ड false है, तो इसका मतलब है कि वर्तनी में कोई सुधार नहीं किया गया है.
USPS डीपीवी की पुष्टि अगर uspsData.dpvConfirmation की वैल्यू Y है, तो इसका मतलब है कि आपका पता, यूएसपीएस के डेटाबेस में मौजूद पते से मेल खाता है. यह फ़ील्ड सिर्फ़ अमेरिका के पतों के लिए उपलब्ध है. uspsData.dpvConfirmation के बारे में ज़्यादा जानकारी के लिए, अमेरिका के पतों को मैनेज करना लेख पढ़ें.

स्वीकार किए जाने वाले पते के उदाहरण