गड़बड़ी के स्टैंडर्ड रिस्पॉन्स
अगर Reporting API का अनुरोध पूरा हो जाता है, तो एपीआई 200 दिखाता है.
अगर अनुरोध के साथ कोई गड़बड़ी होती है, तो एपीआई गड़बड़ी के टाइप के आधार पर रिस्पॉन्स के तौर पर एचटीटीपी स्टेटस कोड, स्टेटस, और वजह दिखाता है.
इसके अलावा, जवाब के मुख्य हिस्से में गड़बड़ी की वजह
की पूरी जानकारी होती है. यहां गड़बड़ी के जवाब का उदाहरण दिया गया है:
{
"error": {
"code": 403,
"message": "User does not have sufficient permissions for this profile.",
"status": "PERMISSION_DENIED"
}
}
गड़बड़ी तालिका
| कोड | स्थिति | ब्यौरा | सुझाई गई कार्रवाई |
|---|---|---|---|
| 400 | INVALID_ARGUMENT |
अनुरोध अमान्य है; हो सकता है कि कोई आवश्यक तर्क मौजूद न हो, सीमा से ज़्यादा हो या उसकी वैल्यू अमान्य हो. | ज़्यादा जानकारी के लिए, गड़बड़ी के मैसेज की समीक्षा करें. अगर क्लाइंट इस गड़बड़ी को फिर से करने की कोशिश करता है, तो यह गड़बड़ी फिर से नहीं होगी. |
| 401 | UNAUTHENTICATED |
क्लाइंट की पुष्टि सही तरीके से नहीं की गई है. | समस्या को ठीक किए बिना फिर से कोशिश न करें. आपको पुष्टि करने के लिए नया टोकन लेना होगा. |
| 403 | PERMISSION_DENIED |
उस डेटा के अनुरोध के बारे में बताता है जिसका ऐक्सेस उपयोगकर्ता के पास नहीं है. | समस्या को ठीक किए बिना फिर से कोशिश न करें. किसी खास इकाई पर कार्रवाई करने के लिए, आपके पास ज़रूरी अनुमतियां होनी चाहिए. |
| 429 | RESOURCE_EXHAUSTED AnalyticsDefaultGroupCLIENT_PROJECT-1d |
इससे पता चलता है कि हर प्रोजेक्ट के लिए हर दिन मिलने वाले अनुरोधों का कोटा खत्म हो गया है. | समस्या को ठीक किए बिना फिर से कोशिश न करें. आपने हर दिन का कोटा खत्म कर लिया है. |
| 429 | RESOURCE_EXHAUSTED AnalyticsDefaultGroupCLIENT_PROJECT-100s |
इससे पता चलता है कि हर प्रोजेक्ट के लिए, हर 100 सेकंड के लिए किए गए अनुरोधों का कोटा खत्म हो गया है. | एक्सपोनेन्शियल बैक-ऑफ़ सुविधा का इस्तेमाल करके फिर से कोशिश करें. आपको अनुरोध भेजने की दर को कम करना होगा. |
| 429 | RESOURCE_EXHAUSTED AnalyticsDefaultGroupUSER-100 |
इससे पता चलता है कि हर प्रोजेक्ट के लिए, हर 100 सेकंड के लिए मिले अनुरोधों की संख्या खत्म हो गई है. | एक्सपोनेन्शियल बैक-ऑफ़ सुविधा का इस्तेमाल करके फिर से कोशिश करें. आपको अनुरोध भेजने की दर को कम करना होगा. |
| 429 | RESOURCE_EXHAUSTED DiscoveryGroupCLIENT_PROJECT-100s |
इससे पता चलता है कि हर 100 सेकंड के लिए अनुरोध करने का कोटा खत्म हो गया है. | खोज रिस्पॉन्स बार-बार नहीं बदलता, खोज रिस्पॉन्स को स्थानीय तौर पर कैश मेमोरी में सेव करें या एक्सपोनेन्शियल बैक-ऑफ़ का इस्तेमाल करके फिर से कोशिश करें. आपको जिस दर पर अनुरोध भेजने हैं उसे धीमा करना होगा. |
| 500 | INTERNAL |
सर्वर में ऐसी गड़बड़ी हुई जिसकी उम्मीद नहीं थी. | इस क्वेरी को एक से ज़्यादा बार दोबारा न खोजें. |
| 503 | BACKEND_ERROR |
सर्वर ने एक गड़बड़ी दी है. | इस क्वेरी को एक से ज़्यादा बार दोबारा न खोजें. |
| 503 | UNAVAILABLE |
सेवा अनुरोध को प्रोसेस नहीं कर सकी. | यह स्थिति कुछ समय के लिए होती है और इसे एक्सपोनेन्शियल बैक-ऑफ़ का इस्तेमाल करके ठीक किया जा सकता है. |
एक्सपोनेन्शियल बैकऑफ़ लागू करना
एक्सपोनेंशियल बैकऑफ़ वह प्रोसेस है जिसमें क्लाइंट, समय-समय पर फ़ेल हो चुके अनुरोध को प्रोसेस करने की कोशिश करता रहता है. यह नेटवर्क ऐप्लिकेशन के लिए, गड़बड़ियों को ठीक करने की स्टैंडर्ड रणनीति है. 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."