इस गाइड में, Merchant API से मिलने वाली गड़बड़ियों को ठीक करने का तरीका बताया गया है. गड़बड़ी के रिस्पॉन्स के स्ट्रक्चर और उसकी स्थिरता को समझना ज़रूरी है. इससे, इंटिग्रेशन को मज़बूत बनाया जा सकता है. साथ ही, गड़बड़ी होने पर, इंटिग्रेशन अपने-आप ठीक हो सकता है या उपयोगकर्ताओं को काम की जानकारी दी जा सकती है.
खास जानकारी
Merchant API का कोई अनुरोध पूरा न होने पर, एपीआई एक स्टैंडर्ड एचटीटीपी स्टेटस कोड (4xx या 5xx) और JSON फ़ॉर्मैट में एक रिस्पॉन्स दिखाता है. इसमें गड़बड़ी के बारे में जानकारी होती है.
Merchant API, गड़बड़ी की जानकारी के लिए AIP-193 स्टैंडर्ड
का पालन करता है. इससे, मशीन से पढ़ी जा सकने वाली जानकारी मिलती है. इसकी मदद से, आपका
ऐप्लिकेशन, गड़बड़ी के खास मामलों को प्रोग्रामैटिक तौर पर ठीक कर सकता है.
गड़बड़ी के रिस्पॉन्स का स्ट्रक्चर
गड़बड़ी का रिस्पॉन्स, एक JSON ऑब्जेक्ट होता है. इसमें code,
message, और status जैसे स्टैंडर्ड फ़ील्ड शामिल होते हैं. खास तौर पर, इसमें details कलेक्शन भी शामिल होता है. गड़बड़ियों को प्रोग्रामैटिक तौर पर ठीक करने के लिए, आपको details में मौजूद किसी ऐसे ऑब्जेक्ट को देखना चाहिए जिसमें @type की वैल्यू type.googleapis.com/google.rpc.ErrorInfo हो.
ErrorInfo ऑब्जेक्ट में, गड़बड़ी के बारे में स्थिर और स्ट्रक्चर्ड डेटा होता है:
- डोमेन: गड़बड़ी का लॉजिकल ग्रुप. आम तौर पर, यह
merchantapi.googleapis.comहोता है. - metadata: गड़बड़ी से जुड़ी डाइनैमिक वैल्यू का मैप. इसमें ये शामिल हैं:
- REASON: गड़बड़ी की सटीक जानकारी देने वाला, स्थिर आइडेंटिफ़ायर. जैसे,
INVALID_NAME_PART_NOT_NUMBER,PERMISSION_DENIED_ACCOUNTS. यह फ़ील्ड हमेशा मौजूद होता है. अपने ऐप्लिकेशन के लॉजिक में, गड़बड़ी को ठीक करने के लिए इस फ़ील्ड का इस्तेमाल करें. - HELP_CENTER_LINK: समस्या को ठीक करने के लिए, ज़्यादा जानकारी और निर्देश देता है. यह फ़ील्ड, सभी गड़बड़ियों के लिए मौजूद नहीं होता. हालांकि, हमारा प्लान है कि समय के साथ-साथ, उन गड़बड़ियों के लिए भी इसे उपलब्ध कराया जाए जिनके लिए ज़्यादा जानकारी की ज़रूरत हो सकती है.
- अन्य डाइनैमिक फ़ील्ड: अन्य कुंजियां, जो संदर्भ देती हैं. जैसे, अमान्य फ़ील्ड का नाम (
FIELD_LOCATION) या वह वैल्यू जिसकी वजह से गड़बड़ी हुई (FIELD_VALUE).
- REASON: गड़बड़ी की सटीक जानकारी देने वाला, स्थिर आइडेंटिफ़ायर. जैसे,
गड़बड़ी के रिस्पॉन्स के उदाहरण
यहां दिए गए JSON से, Merchant API की गड़बड़ी के स्ट्रक्चर के बारे में पता चलता है. इसमें, संसाधन के नाम का फ़ॉर्मैट गलत है.
{
"error": {
"code": 400,
"message": "[name] The part `account` of the resource name in field `name` must be a number, but has value: `abcd`.",
"status": "INVALID_ARGUMENT",
"details": [
{
"@type": "type.googleapis.com/google.rpc.ErrorInfo",
"reason": "invalid",
"domain": "merchantapi.googleapis.com",
"metadata": {
"VARIABLE_NAME": "account",
"FIELD_LOCATION": "name",
"FIELD_VALUE": "abcd",
"REASON": "INVALID_NAME_PART_NOT_NUMBER"
}
}
]
}
}
यहां पुष्टि करने में गड़बड़ी का एक उदाहरण दिया गया है:
{
"error": {
"code": 401,
"message": "The caller does not have access to the accounts: [1234567]",
"status": "UNAUTHENTICATED",
"details": [
{
"@type": "type.googleapis.com/google.rpc.ErrorInfo",
"reason": "unauthorized",
"domain": "merchantapi.googleapis.com",
"metadata": {
"ACCOUNT_IDS": "[1234567]",
"REASON": "PERMISSION_DENIED_ACCOUNTS"
}
}
]
}
}
गड़बड़ी के फ़ील्ड की स्थिरता
गड़बड़ी को ठीक करने का लॉजिक लिखते समय, यह जानना ज़रूरी है कि किन फ़ील्ड पर भरोसा किया जा सकता है और किन में बदलाव हो सकता है.
- स्थिर फ़ील्ड:
details.metadata.REASON: गड़बड़ी का सटीक आइडेंटिफ़ायर. आपको अपने ऐप्लिकेशन के कंट्रोल फ़्लो लॉजिक के लिए इस फ़ील्ड पर भरोसा करना चाहिए.details.metadataकुंजियां: मेटाडेटा मैप में मौजूद कुंजियां (जैसे,FIELD_LOCATION,ACCOUNT_IDS) स्थिर होती हैं.code: हाई-लेवल एचटीटीपी स्टेटस कोड (जैसे,400,401,503) स्थिर होता है.
अस्थिर फ़ील्ड:
message: गड़बड़ी का ऐसा मैसेज जिसे लोग पढ़ सकते हैं, स्थिर नहीं होता. यह सिर्फ़ डेवलपर को डीबग करने के लिए होता है. ऐसा कोड न लिखें जो फ़ील्ड के टेक्स्ट कॉन्टेंट को पार्स करता होmessageया उस पर निर्भर करता हो, क्योंकि इसमें साफ़ तौर पर जानकारी देने या संदर्भ जोड़ने के लिए, बिना सूचना दिए बदलाव किया जा सकता है.details.metadataवैल्यू: कुंजियां स्थिर होती हैं, लेकिन जानकारी देने वाली कुंजियों की वैल्यू में बदलाव हो सकता है. उदाहरण के लिए, अगरHELP_CENTER_LINKकुंजी दी जाती है, तो हो सकता है कि इससे जुड़े यूआरएल को, पहले से सूचना दिए बिना, दस्तावेज़ के नए पेज पर अपडेट कर दिया जाए. हालांकि, जैसा कि पहले बताया गया है,details.metadata.REASONकी वैल्यू स्थिर होती है.
सबसे सही तरीके
यह पक्का करने के लिए कि आपका इंटिग्रेशन, गड़बड़ियों को आसानी से ठीक कर सके, इन सबसे सही तरीकों को अपनाएं.
लॉजिक के लिए details.metadata.REASON का इस्तेमाल करना
गड़बड़ी की वजह जानने के लिए, हमेशा metadata मैप में मौजूद REASON का इस्तेमाल करें. सिर्फ़ एचटीटीपी स्टेटस कोड पर भरोसा न करें, क्योंकि एक ही स्टेटस कोड वाली कई गड़बड़ियां हो सकती हैं.
गड़बड़ी के मैसेज को पार्स न करना
स्थिरता वाले सेक्शन में बताया गया है कि message फ़ील्ड, लोगों के लिए होता है.
अगर आपको डाइनैमिक जानकारी चाहिए (जैसे, कौनसे फ़ील्ड की वैल्यू अमान्य है), तो इसे metadata मैप से निकालें. इसके लिए, FIELD_LOCATION, VARIABLE_NAME जैसी स्थिर कुंजियों का इस्तेमाल करें.
एक्स्पोनेंशियल बैकऑफ़ को लागू करना
ऐसी गड़बड़ियों के लिए एक्स्पोनेंशियल बैकऑफ़ की रणनीति लागू करें जो अस्थायी तौर पर सेवा उपलब्ध न होने या दर की सीमा से ज़्यादा अनुरोध भेजने की वजह से होती हैं. इसका मतलब है कि फिर से कोशिश करने से पहले, कुछ समय इंतज़ार करना. साथ ही, हर बार गड़बड़ी होने पर, इंतज़ार का समय बढ़ाना.
quota/request_rate_too_high: इस गड़बड़ी का मतलब है कि आपने किसी खास कोटा ग्रुप के लिए, हर मिनट के हिसाब से तय कोटा से ज़्यादा अनुरोध भेजे हैं. अनुरोध भेजने की दर कम करें.internal_error: आम तौर पर, ये गड़बड़ियां अस्थायी होती हैं. एक्स्पोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करें.
Merchant API की सहायता टीम से संपर्क करने का तरीका
अगर आपको किसी गड़बड़ी के बारे में Merchant API की सहायता टीम से संपर्क करना है, तो अपने अनुरोध में यह जानकारी दें:
- गड़बड़ी का सटीक रिस्पॉन्स
- एपीआई के तरीके का नाम
- अनुरोध का पेलोड
- टाइमस्टैंप या वह समयावधि जिसके दौरान, तरीके को कॉल किया गया था और गड़बड़ियां मिली थीं