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