ל-Google Calendar API יש מכסות כדי לוודא שכל המשתמשים משתמשים בו בצורה הוגנת. יש שלוש מגבלות חשובות שצריך לקחת בחשבון כשמשתמשים ב-Calendar API:
- מכסות השימוש בממשקי API נאכפות לכל פרויקט ולכל משתמש. מידע נוסף מופיע בקטע הבא.
- מגבלות כלליות על השימוש ביומן: כדאי להימנע ממגבלות על השימוש ביומן.
- מגבלות תפעוליות: יכול להיות שתחול עליכם הגבלת קצב בכל שלב. לדוגמה, אם מנסים לכתוב ליומן יחיד ברצף מהיר.
סוגי מכסות השימוש ב-Calendar API
יש שני סוגים של מכסות:
- לדקה לכל פרויקט: מספר הבקשות שבוצעו על ידי הפרויקט שלכם ב-Google Cloud.
- לדקה לכל פרויקט לכל משתמש: זהו מספר הבקשות שמשתמש מסוים בפרויקט Cloud שלכם יכול לשלוח. המגבלה הזו נועדה לעזור לכם לוודא שהשימוש יתחלק באופן הוגן בין המשתמשים.
המכסות מחושבות לדקה באמצעות חלון הזזה, ולכן אם תהיה עלייה מהירה בתנועה שתחרוג מהמכסה לדקה במהלך דקה אחת, תהיה הגבלת קצב במהלך החלון הבא כדי להבטיח שהשימוש הממוצע יישאר במסגרת המכסות.
אם תחרגו מאחת המכסות, תוגבלו בקצב יצירת הבקשות ותקבלו קוד סטטוס 403 usageLimits או קוד סטטוס 429 usageLimits לשאילתות שלכם. במקרה כזה, אפשר:
- חשוב להקפיד על כל השיטות המומלצות: השהיה מעריכית לפני ניסיון חוזר, הוספת אקראיות לדפוסי התנועה, שימוש בהתראות פוש.
- אם הפרויקט שלכם גדל ויש לכם יותר משתמשים, אתם יכולים לבקש הגדלה של המכסה לכל פרויקט.
- אם מגיעים למכסת ההקצאה לכל משתמש, אפשר לבצע את הפעולות הבאות:
- אם משתמשים בחשבון שירות, צריך להקצות את העומס למשתמשים או לפצל אותו בין כמה חשבונות שירות.
- אפשר לבקש להגדיל את המכסה לכל משתמש, אבל בדרך כלל לא מומלץ להגדיל אותה מעבר לערך ברירת המחדל, כי יכול להיות שהאפליקציה תתחיל להגיע לסוגים אחרים של מגבלות, למשל מגבלות כלליות על השימוש ביומן או מגבלות תפעוליות.
בקשה להגדלת מכסה
כדי לראות או לשנות את מגבלות השימוש בפרויקט, או כדי לבקש הגדלה של המכסה:
- אם עדיין אין לכם חשבון לחיוב לפרויקט, אתם צריכים ליצור חשבון כזה.
- נכנסים לדף Enabled APIs (ממשקי API מופעלים) ב-API library ב-API Console ובוחרים API מהרשימה.
- כדי לראות ולשנות הגדרות שקשורות למכסות, בוחרים באפשרות מכסות. כדי לראות את נתוני השימוש, בוחרים באפשרות שימוש.
שימוש בהשהיה מעריכית לפני ניסיון חוזר (exponential backoff)
אם נרצה שתורידו את קצב הבקשות, נחזיר תגובה 403 usageLimits או תגובה 429 (אפשר לעיין בתיעוד המלא של השגיאות). זו לא שגיאה קריטית, ואנחנו מצפים שתנסו לשלוח את הבקשה שוב אחרי פרק זמן קצר. אם הבקשות עדיין מגיעות מהר מדי, נבקש שוב, וכן הלאה. כדי שהשיטה הזו תפעל בצורה תקינה, חשוב שההשהיות בין הבקשות יגדלו לאורך זמן.
בדרך כלל, כדאי להשתמש בהשהיה מעריכית קטומה לפני ניסיון חוזר. במסמכי Cloud Storage יש הסבר טוב על אופן הפעולה של ההשהיה הזו ועל האלגוריתם המועדף. אם אתם משתמשים בספריית לקוח של Google, בדרך כלל הטיפול בזה מתבצע בשבילכם. כדאי לעיין במסמכי התיעוד של הספרייה. בדרך כלל, מומלץ להשתמש בהטמעה של הספרייה ולא לכתוב הטמעה משלכם.
יצירת דפוסי תנועה אקראיים
לקוחות של יומן נוטים ליצור דפוסי תנועה עם עליות וירידות חדות שנגרמות מכך שמספר לקוחות מבצעים פעולות בו-זמנית. לדוגמה, שיטה לא מומלצת ללקוח של יומן היא לבצע סנכרון מלא בחצות. הסיכוי גבוה מאוד שתחרגו מהמכסה לדקה ותיחסמו אוטומטית או שתהיה השהיה בתגובה.
כדי להימנע מכך, חשוב לפזר את תנועת הגולשים לאורך היום, ככל האפשר. אם הלקוח צריך לבצע סנכרון יומי, צריך לבקש ממנו לקבוע שעה אקראית (שונה לכל לקוח). אם אתם צריכים לבצע פעולה באופן קבוע, כדאי לשנות את המרווח בטווח של +/- 25%. כך התנועה תתחלק בצורה שווה יותר וחוויית המשתמש תהיה טובה יותר.
שימוש בהתראות
תרחיש שימוש נפוץ הוא הרצון לבצע פעולה בכל פעם שמשהו משתנה ביומן של המשתמש. דוגמה לאנטי-תבנית היא שליחת בקשות חוזרות ונשנות לכל לוח שנה שמעניין אתכם. הפעולה הזו תגרום לניצול מהיר מאוד של כל המכסה. לדוגמה, אם לאפליקציה שלכם יש 5,000 משתמשים והיא שולחת שאילתה ליומן של כל משתמש פעם בדקה, היא תדרוש מכסה של לפחות 5,000 לדקה, עוד לפני שהיא מבצעת פעולה כלשהי.
אפליקציות בצד השרת יכולות להירשם לקבלת התראות פוש, וכך נוכל להודיע לכם כשקורה משהו שמעניין אתכם. ההגדרות האלה דורשות יותר עבודה, אבל הן מאפשרות שימוש יעיל יותר במכסת השימוש ומספקות חוויית משתמש טובה יותר. חשוב לציין את eventType שרוצים לקבל עליו התראה. מידע נוסף זמין במאמר בנושא התראות פוש.
ניהול חשבונות תקין באמצעות חשבונות שירות
אם האפליקציה שלכם מבצעת בקשות באמצעות הענקת גישה ברמת הדומיין, כברירת מחדל חשבון השירות מחויב בהתאם למכסות 'לדקה לכל פרויקט לכל משתמש', ולא המשתמש שאתם מתחזים לו. המשמעות היא שסביר להניח שחשבון השירות יגיע למכסה המקסימלית ויחול עליו הגבלת קצב, גם אם הוא פועל ביומנים של כמה משתמשים. כדי להימנע מכך, אפשר להשתמש בפרמטר quotaUser של כתובת ה-URL (או בכותרת x-goog-quota-user HTTP) כדי לציין איזה משתמש יחויב. הערך הזה משמש רק לחישובים של מכסת השימוש. מידע נוסף זמין במאמר הגבלת בקשות לכל משתמש במסמכי התיעוד של Cloud.
בדיקה של טיפול במגבלות מכסה
כדי לוודא שהאפליקציה שלך יכולה להתמודד בצורה חלקה עם הגעה למגבלות מכסת השימוש בפועל (לדוגמה, על ידי ביצוע ניסיונות חוזרים עם השהיה אקספוננציאלית) וכדי למזער שיבושים אפשריים למשתמשים, מומלץ מאוד לבדוק את התרחיש הזה בסביבה אמיתית.
כדי שהבדיקה לא תשפיע על השימוש באפליקציה האמיתית, מומלץ לרשום פרויקט נפרד לבדיקה בלבד ב-Google API Console ולהגדיר אותו באופן דומה לפרויקט הייצור. לאחר מכן תוכלו להגדיר מכסות נמוכות באופן מלאכותי לפרויקט הזה ולבחון את ההתנהגות של האפליקציה.
תמחור
כל השימוש ב-Google Calendar API זמין ללא עלות נוספת. אם חורגים מהמכסה או ממגבלות הבקשות, לא יחויבו חיובים נוספים והחשבון לא יחויב.