Calendar API, गड़बड़ी की जानकारी के दो लेवल दिखाता है:
- हेडर में एचटीटीपी गड़बड़ी के कोड और मैसेज
- जवाब के मुख्य हिस्से में मौजूद JSON ऑब्जेक्ट में, गड़बड़ी के बारे में ज़्यादा जानकारी होती है. इससे आपको यह तय करने में मदद मिलती है कि गड़बड़ी को कैसे ठीक किया जाए.
इस पेज के बाकी हिस्से में, Calendar API से जुड़ी गड़बड़ियों के बारे में बताया गया है. साथ ही, आपके ऐप्लिकेशन में इन गड़बड़ियों को ठीक करने के बारे में कुछ दिशा-निर्देश दिए गए हैं.
एक्स्पोनेंशियल बैकऑफ़ लागू करना
Cloud API के दस्तावेज़ में, एक्सपोनेंशियल बैकऑफ़ के बारे में अच्छी तरह से बताया गया है. साथ ही, यह भी बताया गया है कि Google API के साथ इसका इस्तेमाल कैसे किया जाता है.
गड़बड़ियां और सुझाई गई कार्रवाइयां
इस सेक्शन में, सूची में शामिल हर गड़बड़ी को JSON फ़ॉर्मैट में दिखाया गया है. साथ ही, गड़बड़ी को ठीक करने के लिए सुझाई गई कार्रवाइयां भी दी गई हैं.
400: गलत अनुरोध
उपयोगकर्ता की गड़बड़ी. इसका मतलब यह हो सकता है कि कोई ज़रूरी फ़ील्ड या पैरामीटर नहीं दिया गया है, दी गई वैल्यू अमान्य है या दिए गए फ़ील्ड का कॉम्बिनेशन अमान्य है.
{
"error": {
"errors": [
{
"domain": "calendar",
"reason": "timeRangeEmpty",
"message": "The specified time range is empty.",
"locationType": "parameter",
"location": "timeMax",
}
],
"code": 400,
"message": "The specified time range is empty."
}
}
सुझाई गई कार्रवाई: यह एक स्थायी गड़बड़ी है. इसलिए, इसे ठीक करने के लिए दोबारा कोशिश न करें. गड़बड़ी का मैसेज पढ़ें और उसके मुताबिक अपने अनुरोध में बदलाव करें.
401: अमान्य क्रेडेंशियल
अमान्य ऑथराइज़ेशन हेडर. आपके इस्तेमाल किए जा रहे ऐक्सेस टोकन की समयसीमा खत्म हो गई है या वह अमान्य है.
{
"error": {
"errors": [
{
"domain": "global",
"reason": "authError",
"message": "Invalid Credentials",
"locationType": "header",
"location": "Authorization",
}
],
"code": 401,
"message": "Invalid Credentials"
}
}
सुझाई गई कार्रवाइयां:
- ज़्यादा समय तक इस्तेमाल किए जा सकने वाले रीफ़्रेश टोकन का इस्तेमाल करके, नया ऐक्सेस टोकन पाएं.
- अगर ऐसा नहीं होता है, तो उपयोगकर्ता को OAuth फ़्लो के ज़रिए रीडायरेक्ट करें. इसके बारे में OAuth 2.0 की मदद से अनुरोधों को अनुमति देना लेख में बताया गया है.
- अगर आपको किसी सेवा खाते के लिए यह मैसेज दिख रहा है, तो पक्का करें कि आपने सेवा खाते वाले पेज पर दिए गए सभी चरण पूरे कर लिए हों.
403: User Rate Limit Exceeded
डेवलपर कंसोल की किसी सीमा तक पहुंच गया है.
{
"error": {
"errors": [
{
"domain": "usageLimits",
"reason": "userRateLimitExceeded",
"message": "User Rate Limit Exceeded"
}
],
"code": 403,
"message": "User Rate Limit Exceeded"
}
}
सुझाई गई कार्रवाइयां:
- पक्का करें कि आपका ऐप्लिकेशन, कोटा मैनेज करने से जुड़े सबसे सही तरीकों का पालन करता हो.
- Developer Console प्रोजेक्ट में, हर उपयोगकर्ता के लिए तय की गई सीमा बढ़ाएं.
- अगर कोई उपयोगकर्ता, Google Workspace खाते के कई उपयोगकर्ताओं की ओर से बहुत ज़्यादा अनुरोध कर रहा है, तो पूरे डोमेन के लिए डेलिगेशन की सुविधा वाले सेवा खाते का इस्तेमाल करें और
quotaUserपैरामीटर सेट करें. - एक्स्पोनेंशियल बैकऑफ़ का इस्तेमाल करें.
403: अनुरोधों की दर तय सीमा से ज़्यादा है
उपयोगकर्ता ने Google Calendar API के लिए, हर कैलेंडर या पुष्टि किए गए हर उपयोगकर्ता के लिए अनुरोध की ज़्यादा से ज़्यादा दर पूरी कर ली है.
{
"error": {
"errors": [
{
"domain": "usageLimits",
"reason": "rateLimitExceeded",
"message": "Rate Limit Exceeded"
}
],
"code": 403,
"message": "Rate Limit Exceeded"
}
}
सुझाया गया तरीका: rateLimitExceeded गड़बड़ियों के लिए, 403 या 429 गड़बड़ी कोड दिख सकते हैं. फ़िलहाल, ये दोनों गड़बड़ी कोड एक जैसे हैं. इसलिए, इनका जवाब एक ही तरीके से दिया जाना चाहिए. इसके लिए, एक्सपोनेंशियल बैकऑफ़ का इस्तेमाल करें.
इसके अलावा, पक्का करें कि आपका ऐप्लिकेशन कोटा मैनेज करने के सबसे सही तरीकों का पालन करता हो.
403: कैलेंडर इस्तेमाल करने की सीमाएं पार हो गई हैं
उपयोगकर्ता ने Google Calendar की किसी सीमा को पार कर लिया है. ये सीमाएं, Google के उपयोगकर्ताओं और इंफ़्रास्ट्रक्चर को बुरे बर्ताव से बचाने के लिए तय की गई हैं.
{
"error": {
"errors": [
{
"domain": "usageLimits",
"message": "Calendar usage limits exceeded.",
"reason": "quotaExceeded"
}
],
"code": 403,
"message": "Calendar usage limits exceeded."
}
}
सुझाई गई कार्रवाइयां:
- Calendar के इस्तेमाल की सीमाओं के बारे में ज़्यादा जानने के लिए, Google Workspace एडमिन सहायता केंद्र पर जाएं.
403: आयोजक के अलावा अन्य लोगों के लिए अनुमति नहीं है
इवेंट अपडेट करने का अनुरोध, शेयर किए गए इवेंट की किसी ऐसी प्रॉपर्टी को सेट करने की कोशिश कर रहा है जो आयोजक की कॉपी में नहीं है. शेयर की गई प्रॉपर्टी (उदाहरण के लिए, guestsCanInviteOthers, guestsCanModify या guestsCanSeeOtherGuests) सिर्फ़ आयोजक सेट कर सकता है.
{
"error": {
"errors": [
{
"domain": "calendar",
"reason": "forbiddenForNonOrganizer",
"message": "Shared properties can only be changed by the organizer of the event."
}
],
"code": 403,
"message": "Shared properties can only be changed by the organizer of the event."
}
}
सुझाई गई कार्रवाइयां:
- अगर Events: insert, Events: import या Events: update का इस्तेमाल किया जा रहा है और आपके अनुरोध में कोई भी शेयर की गई प्रॉपर्टी शामिल नहीं है, तो इसका मतलब है कि उन्हें उनकी डिफ़ॉल्ट वैल्यू पर सेट करने की कोशिश की जा रही है. इसके बजाय, Events: patch का इस्तेमाल करें.
- अगर आपके अनुरोध में शेयर की गई प्रॉपर्टी हैं, तो पक्का करें कि आयोजक की कॉपी अपडेट करते समय, सिर्फ़ इन प्रॉपर्टी में बदलाव किया जा रहा हो.
404: नहीं मिला
बताया गया संसाधन नहीं मिला. ऐसा कई मामलों में हो सकता है. यहां कुछ उदाहरण दिए गए हैं:
- जब अनुरोध किया गया संसाधन (दिए गए आईडी के साथ) कभी मौजूद ही नहीं था
जब उपयोगकर्ता ऐसे कैलेंडर को ऐक्सेस करने की कोशिश करता है जिसे वह ऐक्सेस नहीं कर सकता
{ "error": { "errors": [ { "domain": "global", "reason": "notFound", "message": "Not Found" } ], "code": 404, "message": "Not Found" } }
सुझाई गई कार्रवाई: एक्सपोनेंशियल बैकऑफ़ का इस्तेमाल करें.
409: अनुरोध किया गया आइडेंटिफ़ायर पहले से मौजूद है
दिए गए आईडी वाला इंस्टेंस, स्टोरेज में पहले से मौजूद है.
{
"error": {
"errors": [
{
"domain": "global",
"reason": "duplicate",
"message": "The requested identifier already exists."
}
],
"code": 409,
"message": "The requested identifier already exists."
}
}
सुझाई गई कार्रवाई: अगर आपको नया इंस्टेंस बनाना है, तो नया आईडी जनरेट करें. इसके अलावा, update तरीके का इस्तेमाल करें.
409: कॉन्फ़्लिक्ट
events.batch ऑपरेशन में शामिल किसी बैच किए गए आइटम को इसलिए नहीं चलाया जा सकता, क्योंकि ऑपरेशन से जुड़ा कोई विवाद है. यह विवाद, बैच किए गए अन्य आइटम के अनुरोधों से जुड़ा है.
{
"error": {
"errors": [
{
"domain": "global",
"reason": "conflict",
"message": "Conflict"
}
],
"code": 409,
"message": "Conflict"
}
}
सुझाई गई कार्रवाई: बैच में शामिल उन सभी आइटम को हटाएं जो पूरे हो चुके हैं और उन सभी आइटम को भी हटाएं जो पूरे नहीं हो सकते. इसके बाद, बचे हुए आइटम को किसी दूसरे events.batch या उससे जुड़े सिंगल इवेंट ऑपरेशन में फिर से आज़माएं.
410: मौजूद नहीं है
syncToken या updatedMin पैरामीटर अब मान्य नहीं हैं. यह गड़बड़ी तब भी हो सकती है, जब कोई अनुरोध ऐसे इवेंट को मिटाने की कोशिश करता है जिसे पहले ही मिटा दिया गया है.
{
"error": {
"errors": [
{
"domain": "calendar",
"reason": "fullSyncRequired",
"message": "Sync token is no longer valid, a full sync is required.",
"locationType": "parameter",
"location": "syncToken",
}
],
"code": 410,
"message": "Sync token is no longer valid, a full sync is required."
}
}
या
{
"error": {
"errors": [
{
"domain": "calendar",
"reason": "updatedMinTooLongAgo",
"message": "The requested minimum modification time lies too far in the past.",
"locationType": "parameter",
"location": "updatedMin",
}
],
"code": 410,
"message": "The requested minimum modification time lies too far in the past."
}
}
या
{
"error": {
"errors": [
{
"domain": "global",
"reason": "deleted",
"message": "Resource has been deleted"
}
],
"code": 410,
"message": "Resource has been deleted"
}
}
सुझाई गई कार्रवाई: syncToken या updatedMin पैरामीटर के लिए, स्टोर का डेटा मिटाएं और फिर से सिंक करें. ज़्यादा जानकारी के लिए, संसाधनों को बेहतर तरीके से सिंक करना लेख पढ़ें.
पहले से मिटाए गए इवेंट के लिए, कोई और कार्रवाई करने की ज़रूरत नहीं है.
412: पहले से तय की गई शर्त पूरी नहीं की गई
If-match हेडर में दिया गया etag, अब संसाधन के मौजूदा etag से मेल नहीं खाता.
{
"error": {
"errors": [
{
"domain": "global",
"reason": "conditionNotMet",
"message": "Precondition Failed",
"locationType": "header",
"location": "If-Match",
}
],
"code": 412,
"message": "Precondition Failed"
}
}
सुझाई गई कार्रवाई: इकाई को फिर से फ़ेच करें और बदलावों को फिर से लागू करें. ज़्यादा जानकारी के लिए, संसाधनों के खास वर्शन पाना लेख पढ़ें.
429: कई बार अनुरोध किया गया
rateLimitExceeded गड़बड़ी तब होती है, जब उपयोगकर्ता ने तय समय में बहुत ज़्यादा अनुरोध भेजे हों.
{
"error": {
"errors": [
{
"domain": "usageLimits",
"reason": "rateLimitExceeded",
"message": "Rate Limit Exceeded"
}
],
"code": 429,
"message": "Rate Limit Exceeded"
}
}
सुझाया गया तरीका: rateLimitExceeded गड़बड़ियों के लिए, 403 या 429 गड़बड़ी कोड दिख सकते हैं. फ़िलहाल, ये दोनों गड़बड़ी कोड एक जैसे हैं. इसलिए, इनका जवाब एक ही तरीके से दिया जाना चाहिए. इसके लिए, एक्सपोनेंशियल बैकऑफ़ का इस्तेमाल करें.
इसके अलावा, पक्का करें कि आपका ऐप्लिकेशन कोटा मैनेज करने के सबसे सही तरीकों का पालन करता हो.
500: बैकएंड में गड़बड़ी
अनुरोध को प्रोसेस करते समय कोई गड़बड़ी हुई.
{
"error": {
"errors": [
{
"domain": "global",
"reason": "backendError",
"message": "Backend Error",
}
],
"code": 500,
"message": "Backend Error"
}
}
सुझाई गई कार्रवाई: एक्सपोनेंशियल बैकऑफ़ का इस्तेमाल करें.