गड़बड़ी के स्टैंडर्ड रिस्पॉन्स
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-100 |
इससे पता चलता है कि हर प्रोजेक्ट के लिए, 100 सेकंड के अनुरोध का कोटा खत्म हो गया है. | एक्सपोनेन्शियल बैक-ऑफ़ का इस्तेमाल करके फिर से कोशिश करें. आपको अनुरोध भेजने की दर धीमी करनी होगी. |
429 | RESOURCE_EXHAUSTED AnalyticsDefaultGroupUSER-100 |
इससे पता चलता है कि हर प्रोजेक्ट के लिए, हर उपयोगकर्ता के लिए 100 सेकंड के अनुरोध का कोटा खत्म हो गया है. | एक्सपोनेन्शियल बैक-ऑफ़ का इस्तेमाल करके फिर से कोशिश करें. आपको अनुरोध भेजने की दर धीमी करनी होगी. |
429 | RESOURCE_EXHAUSTED DiscoveryGroupCLIENT_PROJECT-100 |
इससे पता चलता है कि हर 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 होने पर एल्गोरिदम खत्म हो जाता है. यह सीमा सिर्फ़ क्लाइंट को फिर से कोशिश करने से रोकने के लिए बनी है. इस वजह से, किसी अनुरोध को "ठीक नहीं की जा सकने वाली गड़बड़ी" माने जाने से पहले, करीब 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."