गड़बड़ी के स्टैंडर्ड रिस्पॉन्स
रीयल टाइम रिपोर्टिंग एपीआई का अनुरोध स्वीकार होने पर, एपीआई 200
स्टेटस कोड दिखाता है. अगर अनुरोध के साथ कोई गड़बड़ी होती है, तो एपीआई गड़बड़ी के टाइप के आधार पर रिस्पॉन्स के तौर पर एचटीटीपी स्टेटस कोड, स्टेटस, और वजह दिखाता है.
इसके अलावा, जवाब के मुख्य हिस्से में गड़बड़ी की वजह
की पूरी जानकारी होती है. यहां गड़बड़ी के जवाब का उदाहरण दिया गया है:
{
"error": {
"errors": [
{
"domain": "global",
"reason": "invalidParameter",
"message": "Invalid value '-1' for max-results. Value must be within the range: [1, 1000]",
"locationType": "parameter",
"location": "max-results"
}
],
"code": 400,
"message": "Invalid value '-1' for max-results. Value must be within the range: [1, 1000]"
}
}
गड़बड़ी तालिका
कोड | वजह | ब्यौरा | सुझाई गई कार्रवाई |
---|---|---|---|
400 | invalidParameter |
इससे पता चलता है कि अनुरोध पैरामीटर में अमान्य वैल्यू है. गड़बड़ी के जवाब में locationType और location फ़ील्ड से जानकारी मिलती है कि कौनसी वैल्यू अमान्य थी. |
समस्या को ठीक किए बिना फिर से कोशिश न करें. आपको गड़बड़ी के जवाब में बताए गए पैरामीटर के लिए मान्य वैल्यू देनी होगी. |
400 | badRequest |
इससे पता चलता है कि क्वेरी अमान्य थी. उदाहरण के लिए, पैरंट आईडी मौजूद नहीं था या डाइमेंशन या मेट्रिक का अनुरोध मान्य नहीं था. | समस्या को ठीक किए बिना फिर से कोशिश न करें. एपीआई क्वेरी काम करे, इसके लिए आपको उसमें बदलाव करने होंगे. |
401 | invalidCredentials |
इससे पता चलता है कि पुष्टि करने वाला टोकन अमान्य है या इसकी समयसीमा खत्म हो गई है. | समस्या को ठीक किए बिना फिर से कोशिश न करें. आपको पुष्टि करने के लिए नया टोकन लेना होगा. |
403 | insufficientPermissions |
इससे पता चलता है कि उपयोगकर्ता के पास क्वेरी में बताई गई इकाई के लिए, ज़रूरी अनुमतियां नहीं हैं. | समस्या को ठीक किए बिना फिर से कोशिश न करें. किसी खास इकाई पर कार्रवाई करने के लिए, आपके पास ज़रूरी अनुमतियां होनी चाहिए. |
403 | dailyLimitExceeded |
इससे पता चलता है कि उपयोगकर्ता ने हर प्रोजेक्ट के लिए या हर व्यू (प्रोफ़ाइल) के लिए, हर दिन की तय सीमा पार कर ली है. | समस्या को ठीक किए बिना फिर से कोशिश न करें. आपने हर दिन का कोटा खत्म कर लिया है. एपीआई की सीमाएं और कोटा देखें. |
403 | userRateLimitExceeded |
इससे पता चलता है कि हर उपयोगकर्ता के लिए, हर 100 सेकंड में क्वेरी की सीमा पार हो गई है. Google API कंसोल में सेट किया गया डिफ़ॉल्ट मान, हर उपयोगकर्ता के हिसाब से हर 100 सेकंड में 100 क्वेरी है. Google API कंसोल में इस सीमा को ज़्यादा से ज़्यादा 1,000 तक बढ़ाया जा सकता है. | एक्सपोनेन्शियल बैक-ऑफ़ सुविधा का इस्तेमाल करके फिर से कोशिश करें. आपको अनुरोध भेजने की दर को कम करना होगा. |
403 | rateLimitExceeded |
इससे पता चलता है कि प्रोजेक्ट के लिए, हर 100 सेकंड में क्वेरी करने की दर की सीमा पार हो गई है. | एक्सपोनेन्शियल बैक-ऑफ़ सुविधा का इस्तेमाल करके फिर से कोशिश करें. आपको अनुरोध भेजने की दर को कम करना होगा. |
403 | quotaExceeded |
इससे पता चलता है कि कोर रिपोर्टिंग एपीआई में, हर व्यू (प्रोफ़ाइल) के लिए एक साथ 10 अनुरोध किए जा चुके हैं. | घातीय बैक-ऑफ़ का इस्तेमाल करके फिर से कोशिश करें. इस व्यू (प्रोफ़ाइल) के पूरे होने के लिए, आपको कम से कम एक ऐसे अनुरोध की इंतज़ार करना होगा, जिस पर काम जारी है. |
500 | internalServerError |
सर्वर में ऐसी गड़बड़ी हुई जिसकी उम्मीद नहीं थी. | इस क्वेरी को एक से ज़्यादा बार दोबारा न खोजें. |
503 | backendError |
सर्वर ने एक गड़बड़ी दी है. | इस क्वेरी को एक से ज़्यादा बार दोबारा न खोजें. |
500 या 503 रिस्पॉन्स को मैनेज करना
बहुत ज़्यादा लोड होने के दौरान या ज़्यादा मुश्किल अनुरोधों की वजह से, 500
या 503
गड़बड़ी हो सकती है. ज़्यादा अनुरोधों के लिए, कम समय में डेटा का अनुरोध करें. एक्सपोनेन्शियल बैकऑफ़ लागू करने के बारे में भी सोचें.
इन गड़बड़ियों की फ़्रीक्वेंसी, व्यू (प्रोफ़ाइल) और उस व्यू से जुड़े रिपोर्टिंग डेटा की मात्रा पर निर्भर हो सकती है. यह ज़रूरी नहीं है कि किसी क्वेरी की वजह से एक व्यू (प्रोफ़ाइल) के लिए 500
या 503
गड़बड़ी हो. यह ज़रूरी नहीं है कि उसी क्वेरी के लिए, किसी दूसरे व्यू (प्रोफ़ाइल) वाली क्वेरी से गड़बड़ी हो.
एक्सपोनेन्शियल बैकऑफ़ लागू करना
एक्सपोनेंशियल बैकऑफ़ वह प्रोसेस है जिसमें क्लाइंट, समय-समय पर फ़ेल हो चुके अनुरोध को प्रोसेस करने की कोशिश करता रहता है. यह नेटवर्क ऐप्लिकेशन के लिए, गड़बड़ियों को ठीक करने की स्टैंडर्ड रणनीति है. Real Time Reporting API को इस उम्मीद के हिसाब से डिज़ाइन किया जाता है कि जिन क्लाइंट ने पूरे नहीं होने वाले अनुरोधों को फिर से प्रोसेस करने का विकल्प चुना वे ऐसा एक्स्पोनेंशियल बैकऑफ़ का इस्तेमाल करके करें. "ज़रूरी" होने के अलावा, एक्सपोनेन्शियल बैकऑफ़ का इस्तेमाल करने से बैंडविथ इस्तेमाल की क्षमता बढ़ जाती है. साथ ही, एक कामयाब रिस्पॉन्स पाने के लिए ज़रूरी अनुरोधों की संख्या कम होती है, और एक ही समय में एक साथ किए जाने वाले एनवायरमेंट में अनुरोधों की संख्या बढ़ती है.
सामान्य एक्सपोनेन्शियल बैकऑफ़ लागू करने का फ़्लो इस तरह है.
- एपीआई से अनुरोध करें
- गड़बड़ी का ऐसा गड़बड़ी कोड मिला है जिसके लिए फिर से कोशिश की जा सकती है
- 1 सेकंड +
random_number_milliseconds
सेकंड इंतज़ार करें - फिर से अनुरोध करें
- गड़बड़ी का ऐसा गड़बड़ी कोड मिला है जिसके लिए फिर से कोशिश की जा सकती है
- 2 सेकंड +
random_number_milliseconds
सेकंड इंतज़ार करें - फिर से अनुरोध करें
- गड़बड़ी का ऐसा गड़बड़ी कोड मिला है जिसके लिए फिर से कोशिश की जा सकती है
- 4 सेकंड +
random_number_milliseconds
सेकंड इंतज़ार करें - फिर से अनुरोध करें
- गड़बड़ी का ऐसा गड़बड़ी कोड मिला है जिसके लिए फिर से कोशिश की जा सकती है
- 8 सेकंड +
random_number_milliseconds
सेकंड इंतज़ार करें - फिर से अनुरोध करें
- गड़बड़ी का ऐसा गड़बड़ी कोड मिला है जिसके लिए फिर से कोशिश की जा सकती है
- 16 सेकंड +
random_number_milliseconds
सेकंड इंतज़ार करें - फिर से अनुरोध करें
- अगर आपको अब भी गड़बड़ी का कोई मैसेज मिलता है, तो उसे रोकें और लॉग करें.
ऊपर दिए गए फ़्लो में, random_number_milliseconds
, 1,000 से कम या उसके बराबर मिलीसेकंड की कोई रैंडम संख्या है. यह ज़रूरी है,
ताकि एक साथ लागू किए जाने वाले कुछ वर्शन में लॉक से जुड़ी कुछ गड़बड़ियों से बचा जा सके.
हर इंतज़ार के बाद, random_number_milliseconds
को फिर से तय करना होगा.
ध्यान दें: इंतज़ार हमेशा
(2 ^ n) + random_number_milliseconds
होता है, जहां
n एक मोनोटोनिक रूप से बढ़ने वाला पूर्णांक है, जिसे शुरू में
0 के रूप में परिभाषित किया गया है. हर इटरेशन (हर अनुरोध) के लिए n को 1 से बढ़ाया जाता है.
n के 5 होने पर एल्गोरिदम को खत्म करने के लिए सेट किया गया है. यह सीमा सिर्फ़ क्लाइंट को बार-बार कोशिश करने से रोकने के लिए की जाती है. इसकी वजह से, किसी अनुरोध को "ठीक नहीं की जा सकने वाली गड़बड़ी" माने जाने में करीब 32 सेकंड की देरी हो सकती है.
नीचे दिया गया Python कोड, ऊपर दिए गए फ़्लो को लागू करने का तरीका है. इससे, makeRequest
नाम के तरीके में होने वाली गड़बड़ियों को ठीक किया जा सकता है.
import random import time from apiclient.errors import HttpError def makeRequestWithExponentialBackoff(analytics): """Wrapper to request Google Analytics data with exponential backoff. The makeRequest method accepts the analytics service object, makes API requests and returns the response. If any error occurs, the makeRequest method is retried using exponential backoff. Args: analytics: The analytics service object Returns: The API response from the makeRequest method. """ for n in range(0, 5): try: return makeRequest(analytics) except HttpError, error: if error.resp.reason in ['userRateLimitExceeded', 'quotaExceeded', 'internalServerError', 'backendError']: time.sleep((2 ** n) + random.random()) else: break print "There has been an error, the request never succeeded."