इस दस्तावेज़ में, असल दुनिया के कई ऐसे उदाहरणों के बारे में बताया गया है जहां पता की पुष्टि करने वाला एपीआई, उन पतों के लिए जवाब के सिग्नल देता है जिनके लिए आपके सिस्टम को पुष्टि करने की ज़रूरत होती है. संदर्भ के लिए, पुष्टि करने का लॉजिक बनाएं में वर्कफ़्लो की खास जानकारी देखें.
सामान्य उदाहरण: पुष्टि करें
इस उदाहरण में, एक जैसे सड़क के नाम वाले मेट्रोपॉलिटन इलाकों के बारे में बताया गया है. मान लें कि किसी उपयोगकर्ता को अमेरिका के वाशिंगटन के किर्कलैंड में Google बिल्डिंग D का पता डालना है. हालांकि, शहर के तौर पर किर्कलैंड के बजाय, वे गलती से सिऐटल डाल देते हैं.
डाला गया पता | क्षेत्र |
---|---|
बिल्डिंग D, 451 7th Avenue South, Seattle, WA 98033 | अमेरिका |
बदले गए डेटा के लिए फ़ैसला
यहां दिए गए उदाहरण में, जवाब से मिले अहम सिग्नल पर ज़ोर दिया गया है.
{
"inputGranularity": "SUB_PREMISE",
"validationGranularity": "PREMISE_PROXIMITY",
"geocodeGranularity": "PREMISE_PROXIMITY",
"addressComplete": true,
"hasUnconfirmedComponents": true
"hasReplacedComponents": true
}
PREMISE_PROXIMITY
, बिल्डिंग के लेवल के पते के आस-पास के पते की जानकारी देता है. हालांकि, इसमें SUB_PREMISE
के मुकाबले ज़्यादा जानकारी नहीं होती. SUB_PREMISE
, इनपुट के आधार पर दी गई ज़्यादा जानकारी होती है.
जवाब में, पुष्टि नहीं किए गए और बदले गए कॉम्पोनेंट, दोनों शामिल हैं. इसलिए, इस कॉम्बिनेशन को पुष्टि करें कैटगरी में रखा गया है.
पते के कॉम्पोनेंट की क्वेरी से, इन समस्याओं का पता चलता है:
{
"componentName": {
"text": "451",
},
"componentType": "street_number",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
...
{
"componentName": {
"text": "98104",
},
"componentType": "postal_code",
"confirmationLevel": "CONFIRMED",
"replaced": true
}
...
{
"componentName": {
"text": "Building D",
"language_code": "en"
},
"componentType": "subpremise",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
.......
"unconfirmedComponentTypes": [
"street_number",
"subpremise"
]
इस मामले में, पते की पुष्टि करने वाले एपीआई को सिएटल में दिए गए पते से मिलता-जुलता पता मिला. साथ ही, उसने सिएटल के पते का पता लगाने के लिए, ज़िप कोड को हटा दिया, जो एक बेहतर लेवल का कॉम्पोनेंट है. यह सही विकल्प हो सकता है. हालांकि, कॉम्पोनेंट की पुष्टि नहीं की गई थी. इसलिए, यह पक्का करना ज़रूरी है कि उपयोगकर्ता का मकसद सिएटल का पता डालना है, न कि किर्कलैंड जैसा कोई दूसरा पता.
कभी-कभी होने वाले मामले के उदाहरण: पुष्टि करना
यहां दिए गए उदाहरणों में, अलग-अलग तरह के एज केस दिखाए गए हैं:
- ऐसे छोटे अनुमान जिनकी पुष्टि की जा चुकी है. पते की पुष्टि करने वाला एपीआई, देश, पिन कोड या राज्य का अनुमान लगाता है. हालांकि, बाकी सभी जानकारी दी जाती है और उसकी पुष्टि की जाती है. ज़्यादा जानकारी और पुष्टि के लेवल, दोनों के कॉम्बिनेशन से एक छोटा सा अनुमान लगाया जाता है. इसके लिए, पुष्टि करने की ज़रूरत नहीं होती.
- पते के अनचाहे कॉम्पोनेंट की पुष्टि नहीं की गई. पते के ऐसे कॉम्पोनेंट जिनकी पुष्टि नहीं हुई है, वे पते के जोखिम के लेवल को बढ़ा देते हैं. इसकी पुष्टि की जा सकती है.
- पते का ऐसा अनचाहा कॉम्पोनेंट जिसकी पुष्टि हो चुकी है. सही पते के लिए, इस कॉम्पोनेंट की ज़रूरत ज़रूरी नहीं है. साथ ही, पते की पुष्टि करने वाला एपीआई, इसे आउटपुट से हटा देता है. आम तौर पर, फ़ॉर्मैट करने से जुड़ी समस्याओं की पुष्टि ज़रूरी नहीं होती.
ऐसे छोटे-मोटे अनुमान जिनकी पुष्टि हो चुकी है
ज़्यादा जानकारी वाले पुष्टि किए गए डेटा के साथ जोड़े जाने पर, एपीआई अब भी सही अनुमान लगा सकता है. ऐसा तब होता है, जब इनमें से किसी एक कॉम्पोनेंट का इनपुट मौजूद न हो:
- शहर
- स्थिति
- पिन कोड
- देश
उदाहरण के लिए, कोई ग्राहक मैसाचुसेट्स के स्प्रिंगफ़ील्ड में मौजूद मैकडॉनल्ड्स रेस्टोरेंट का मान्य पता देता है, लेकिन शहर की जानकारी नहीं देता. साथ ही, चार अंकों के एक्सटेंशन के बिना पिन कोड देता है.
डाला गया पता | क्षेत्र |
---|---|
1402 Allen St, MA 01118 | अमेरिका |
शहर की जानकारी मौजूद न होने पर मिलने वाला फ़ैसला
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"addressComplete": true,
"hasInferredComponents": true
}
जिन मामलों में पते की पुष्टि करने वाला एपीआई, डिलीवर किए जा सकने वाले पते का पता लगाने के लिए, ज़्यादा लेवल के कॉम्पोनेंट का अनुमान लगाता है, उनमें आपको इस बात का ज़्यादा भरोसा हो सकता है कि सिस्टम का डेटा सही है. ऐसा इसलिए होता है, क्योंकि अनुमानित घटक, बड़े भौगोलिक इलाके को दिखाते हैं. इसलिए, इनका मिलान, पुष्टि किए गए पते के उन घटकों से आसानी से हो जाता है जो ज़्यादा जानकारी वाले होते हैं. जिन देशों में शहरों के नाम एक जैसे होते हैं, जैसे कि अमेरिका में स्प्रिंगफ़ील्ड, वहां भी शहर के नाम के साथ अन्य कॉम्पोनेंट जोड़कर यूनीक पता दिया जा सकता है.
ऊपर दिए गए उदाहरण का इस्तेमाल करके, पते के सभी कॉम्पोनेंट को स्कैन करने से पता चलता है कि हर कॉम्पोनेंट की पुष्टि हो चुकी है. इसका मतलब है कि यह पते की पुष्टि करने वाले एपीआई से सेव किए गए डेटा से मेल खाता है. साथ ही, यह सेवा दो उच्च-लेवल के कॉम्पोनेंट का भी अनुमान लगाती है.
{
"componentName": {
"text": "Springfield",
"languageCode": "en"
},
"componentType": "locality",
"confirmationLevel": "CONFIRMED",
"inferred": true
},
{
"componentName": {
"text": "1806"
},
"componentType": "postal_code_suffix",
"confirmationLevel": "CONFIRMED",
"inferred": true
}
पते के किसी ऐसे घटक की पुष्टि नहीं की गई है जो आम तौर पर नहीं होता
इस उदाहरण से पता चलता है कि जब कॉम्पोनेंट की पुष्टि नहीं की गई हो, तब जांच करना कितना ज़रूरी है. अगर कोई पता कॉम्पोनेंट अनचाहा है, तो पते की पुष्टि करने वाला एपीआई उसे आउटपुट से हटा देता है. इन मामलों में, आपके पास पते को स्वीकार करने या ग्राहक से फिर से पुष्टि करने का विकल्प होता है. यह विकल्प, जोखिम के लेवल और आपके भरोसे के लेवल पर निर्भर करता है.
उदाहरण के लिए, ऐसा हो सकता है कि कोई पता किसी ऐसे इलाके का हो जहां खरीदार अक्सर ऐसी जानकारी डालते हों जिसे डाक विभाग अनदेखा कर देता है. ऐसे में, आपको उस पते को स्वीकार करना होगा. हालांकि, कुछ मामलों में ऐसा हो सकता है कि पुष्टि न किए गए कॉम्पोनेंट में ग्राहक को अपनी ज़रूरत के मुताबिक कॉम्पोनेंट न मिले.
डाला गया पता | क्षेत्र |
---|---|
1 Rue Grenache, la caritat 2, 34630 Saint-Thibéry | फ़्रांस |
पते के अनचाहे कॉम्पोनेंट के लिए फ़ैसले की पुष्टि नहीं की गई
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"unconfirmedComponents": true
}
पुष्टि नहीं किए गए कॉम्पोनेंट के साथ फ़ैसले के अलावा, Address Validation API, फ़ॉर्मैट किया गया यह पता दिखाता है:
"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",
पुष्टि नहीं किए गए कॉम्पोनेंट के लिए स्कैन करने पर पता चलता है कि एपीआई ने रिटर्न किए गए पते से la caritat 2 को हटा दिया है:
{
"componentName": {
"text": "la caritat 2",
"languageCode": "fr"
},
"componentType": "sublocality_level_1",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
"unexpected": true
}
अनचाहा पता, जिसकी पुष्टि हो चुकी है
इस उदाहरण में, दिए गए पते में यूके की काउंटी शामिल की गई है. ऐसा करना आम बात है. हालांकि, यूके की डाक विभाग की ओर से यह ज़रूरी नहीं है और इसे आम तौर पर अनदेखा कर दिया जाता है. postoffice.co.uk और यूनाइटेड किंगडम और अंतरराष्ट्रीय मेल के लिए पता लिखने का तरीका देखें.
इस वजह से, जब कोई ग्राहक यूके के पते में काउंटी की जानकारी देता है, तो सेवा इसे अनचाहे इनपुट के तौर पर लेती है.
डाला गया पता | क्षेत्र |
---|---|
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP | यूनाइटेड किंगडम |
ऐसे पते के कॉम्पोनेंट के लिए फ़ैसला जिसकी पुष्टि की जा चुकी है
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE"
}
यहां, address_complete
का आकलन गलत के तौर पर किया गया है. साथ ही, पते के कॉम्पोनेंट का विश्लेषण करने पर, एक ऐसा फ़्लैग दिखता है जिसकी उम्मीद नहीं थी.
{
"componentName": {
"text": "Gloucestershire",
"languageCode": "en"
},
"componentType": "administrative_area_level_2",
"confirmationLevel": "CONFIRMED",
"unexpected": true
}
डाले गए पते के लिए, ग्लूस्टरशायर सही काउंटी है. हालांकि, पते का फ़ॉर्मैट गलत है. याद रखें कि पता की पुष्टि करने वाला एपीआई, सही फ़ॉर्मैट के लिए जानकारी का आकलन भी करता है.