מגבלות ומכסות מגנות על התשתית של Google מפני תהליך אוטומטי שמשתמש ב-Data Transfer API באופן בלתי הולם. בקשות מוגזמות מ-API עלולות לנבוע משגיאת הקלדה לא מזיקה, או ממערכת שלא מעוצבת בצורה יעילה שמבצעת קריאות חסרות ל-API. לא משנה מה הסיבה, חסימת תנועה ממקור ספציפי כשהיא מגיעה לרמה מסוימת הכרחית לתקינות הכוללת של מערכת Google Workspace. כך אפשר להבטיח שהפעולות של מפתח אחד לא ישפיעו לרעה על הקהילה הרחבה יותר.
בקשות API שנכשלו
במקרה הלא סביר שבו בקשת ה-API שלך נכשלת, האפליקציה שלך מקבלת תגובת קוד סטטוס HTTP. קוד הסטטוס של 403 מכיל פרטי שגיאה לגבי קלט שגוי, וקוד סטטוס HTTP של 503 מכיל פרטי שגיאה שמציין שחרגת ממכסות ה-API. התגובות האלה מאפשרות לאפליקציה המותאמת אישית לזהות את השגיאות האלה ולנקוט פעולה מתאימה.
השלמת בקשות בפרק זמן קבוע
אם צריך להשלים את הבקשות בפרק זמן קבוע, יש לשלוח את הבקשות במקביל או להשתמש במספר שרשורים באפליקציית Java או C#. לדוגמה, אפשר לפרט את הבקשות לפי חודש או לפי תקופה אחרת. במקרה של שרשורים, כדאי לנסות להתחיל עם 10 שרשורים, שרשור אחד לכל בקשה. ההמלצה לשרשורים היא חסרת טעם והיא לא שימושית לכל מצבי ה-API. אם מספר הבקשות יהיה גבוה מדי, יקרו שגיאות במכסה.
שגיאות מבוססות זמן
בכל השגיאות המבוססות על זמן (עד N שניות ל-X שניות לשרשור), ובמיוחד
שגיאות בקוד הסטטוס 503, מומלץ לקודד על החריגה. באמצעות
אלגוריתם ההשהיה מעריכית, מומלץ להמתין מעט לפני שמנסים לבצע שוב את הקריאה שנכשלה. דוגמה ל-Data Transfer API של שרשור אחד: להמתין 5 שניות ולנסות שוב לבצע את הקריאה שנכשלה. אם הבקשה תאושר,
כדאי לחזור על הדפוס הזה בשרשורים האחרים. אם הבקשה השנייה לא הצליחה, האפליקציה צריכה להפסיק את תדירות הפעולה של הבקשה עד שהשיחה תסתיים בהצלחה. לדוגמה, אפשר להאריך את משך ההשהיה הראשוני של 5 שניות ל-10 שניות ולנסות שוב לבצע את השיחה שנכשלה. בנוסף,
קובעים מגבלה על מספר הניסיונות החוזרים. לדוגמה, אפשר לנסות לשלוח בקשה חוזרת 5 עד 7 פעמים עם זמני השהיה שונים,
לפני שהאפליקציה תחזיר שגיאה למשתמש.
מגבלות
| קטגוריות של מגבלות API | מגבלות |
|---|---|
| שאילתות לשנייה (QPS) | המגבלה של פרויקט הפיתוח היא 10 שאילתות לשנייה (QPS) לכל חשבון. |
מכסות
| קטגוריות של מכסות ל-API | מכסות |
|---|---|
| מספר מקסימלי של בקשות API ליום | המספר המקסימלי של בקשות API ליום הוא 500,000. |
| העברה לארכיון, תפוגה של הודעות | לארכיונים של קבוצות אין תאריך תפוגה. הודעות נשארות בארכיון עד למחיקת הקבוצה. מדיניות שמירת האימייל לא משפיעה על הודעות בארכיון של קבוצה. |
| גודל הודעת אימייל | הגודל המקסימלי של הודעת דואר הוא 25MB. המגבלה הזו כוללת את כותרות המטא-נתונים של ההודעה, את גוף ההודעה ואת כל הקבצים המצורפים. |
סוגים נוספים של מגבלות
| סוגים נוספים של מגבלות | מגבלות והנחיות |
|---|---|
| פורמטים של סוג תוכן | הודעת האימייל חייבת להיות בפורמט הטקסט הסטנדרטי RFC 822.
הפורמט של סוג התוכן של בקשה להעלאת אימיילים שהועברו כולל את הכותרת Content-type: message/rfc822.
|
| פורמט הנתונים בתגובות API | פורמט הנתונים של התגובה הוא JavaScript Object Notation (JSON). |
| מדיניות בנושא מיקום נתונים | Data Transfer API לא תומך במדיניות בנושא מיקום נתונים, שמחייבת אחסון של נתונים בגבולות גיאוגרפיים או פוליטיים ספציפיים מסיבות חוזיות. אין להשתמש ב-Data Transfer API אם מיקום הנתונים נדרש בחשבון. |
| הכנסות הודעה מקבילות | Data Transfer API תומך בבקשות מקבילות להכנסת אימיילים לארכיונים שונים של קבוצות. אבל Data Transfer API לא תומך בהכנסה מקבילה של הודעות לאותו ארכיון קבוצתי. גם בקשות אצווה לא נתמכות בגרסה הזו של ה-API. |
| בקשות לא מורשות | בקשות לא מורשות לא יתקבלו ב-Data Transfer API. בקשה נחשבת לא מורשית אם לא סיפקתם אסימון הרשאה. |