इस गाइड में, 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 ऑब्जेक्ट, गड़बड़ी के बारे में स्टेबल और स्ट्रक्चर्ड डेटा उपलब्ध कराता है:
- domain: गड़बड़ी का लॉजिकल ग्रुप, आम तौर पर
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 फ़ील्ड का इस्तेमाल लोग करते हैं.
अगर आपको डाइनैमिक जानकारी चाहिए (जैसे कि कौनसा फ़ील्ड अमान्य था), तो FIELD_LOCATION, VARIABLE_NAME जैसी स्टेबल कुंजियों का इस्तेमाल करके, इसे metadata मैप से निकालें.
एक्स्पोनेंशियल बैकऑफ़ को लागू करना
अगर आपको कुछ समय के लिए सेवा उपलब्ध न होने या अनुरोध संख्या सीमित होने की गड़बड़ियां दिखती हैं, तो एक्स्पोनेंशियल बैकऑफ़ रणनीति लागू करें. इसका मतलब है कि फिर से कोशिश करने से पहले कुछ देर इंतज़ार करें. साथ ही, हर बार कोशिश नाकाम होने पर इंतज़ार का समय बढ़ाएं.
quota/request_rate_too_high: इस गड़बड़ी से पता चलता है कि आपने किसी खास कोटा ग्रुप के लिए, मिनट का कोटा पार कर लिया है. अनुरोध दर कम करें.internal_error: आम तौर पर, ये गड़बड़ियां कुछ समय के लिए होती हैं. एक्स्पोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करें.
Merchant API की सहायता टीम से संपर्क करने का तरीका
अगर आपको किसी गड़बड़ी के बारे में Merchant API की सहायता टीम से संपर्क करना है, तो अपने अनुरोध में यह जानकारी दें:
- गड़बड़ी का सटीक मैसेज
- एपीआई के तरीके का नाम
- अनुरोध का पेलोड
- टाइमस्टैंप या वह समयसीमा जिसके दौरान तरीके को कॉल किया गया था और गड़बड़ियां मिली थीं