איפה מנהלים את ה-Client-ID במסוף Google Cloud
פונקציית הניהול של מזהה הלקוח בתוכנית Premium זמינה במסוף Cloud שנמצא בחלק התחתון של דף פרטי הכניסה לפלטפורמה של מפות Google, בקטע Client-ID.
כדי לגשת למשימות נוספות של ניהול מזהי לקוח, כולל הרשאה של כתובות URL וניהול סודות של חתימות על מזהי לקוח, אפשר ללחוץ על סמל העריכה בקצה השמאלי של הקטע Client-ID כדי לגשת למשימות נוספות.
חשוב: תוכנית הפרימיום של הפלטפורמה של מפות Google לא זמינה יותר להרשמה או ללקוחות חדשים.
להבטיח שלצוות שלכם יש גישה למשאבים הנחוצים
השימוש ב-Google Cloud Console
למה זה חשוב: מסוף Google Cloud מעניק לכם גישה למידע כמו דוחות שימוש, פידים של חדשות ומשאבים למפתחים. חשוב מכך, במסוף Cloud אפשר לשלוח בקשות תמיכה לצוות התמיכה בפלטפורמה של מפות Google במקרה של בעיות טכניות במהלך הפיתוח או ההפעלה.
לפני ההשקה, צריך לתת גישה למסוף Cloud לכל המפתחים שאחראים לתחזוקת האפליקציה. במקרה של בעיות טכניות, הגישה למסוף Cloud תאפשר לחברי הצוות לפנות לתמיכה וגם לאפשר לצוות התמיכה ליצור קשר עם בעלי העניין המתאימים בארגון. לדוגמה, ייתכן שצוות התמיכה יצטרך ליצור קשר עם הארגון שלך אם נזהה תנועה או התנהגות חריגה שעלולים לגרום לשיבושים באפליקציה. היכולת להיות מסוגלת ליצור קשר עם המפתחים המתאימים יכולה להיות ההבדל בין הפסקה זמנית בשירות לבין מניעה של הפסקה זמנית בשירות.
הרשמה לקבלת התראות על קבוצות באימייל
למה זה חשוב: כדי להתעדכן לגבי הפיתוחים והשינויים בממשקי ה-API של מפות Google, מומלץ להירשם לאחת או יותר מקבוצות האימייל הבאות:
- google-maps-platform-notifications – עדכונים טכניים לגבי שירותי האינטרנט וממשקי ה-API של הפלטפורמה של מפות Google, התראות על הפסקות זמניות בשירות והודעות על תכונות בפלטפורמה (כ-3 עד 5 הודעות בחודש).
- google-maps-js-api-v3-notify - גרסאות חדשות של ממשק ה-API של JavaScript במפות Google (כ-4 הודעות בשנה).
אופטימיזציה של האפליקציה
הגדרה של חומת אש כדי לאפשר גישה לשירותי הפלטפורמה של מפות Google
למה זה חשוב: שירותי הפלטפורמה של מפות Google משתמשים במגוון
דומיינים, חלקם לא שייכים לדומיין *google.com. אם פועלים מאחורי חומת אש מגבילה, חשוב לאפשר גישה לדומיינים שמשמשים את כל אחד משירותי ה-API של מפות Google. אם חומת האש לא מאפשרת גישה לדומיינים האלה, בקשות ה-API ייכשלו, וזה עלול לפגוע באפליקציות. לרשימה המלאה של הדומיינים שמשמשים את ממשקי ה-API של מפות Google
אנחנו לא ממליצים לנהל את ההגבלות על חומת האש לפי כתובת IP, כי כתובות ה-IP שמשויכות לדומיינים האלה לא סטטיות.
הערה: שירותי הפלטפורמה של מפות Google משתמשים ביציאה 80 (http) וב-443 (https) לתנועה נכנסת ויוצאת. לשירותים האלה נדרשות גם בקשות GET, POST, PUT, DELETE ו-HEAD. מגדירים את חומת האש כדי לאפשר תעבורת נתונים ביציאות האלה ולאפשר בקשות, בהתאם ל-API ולתרחיש לדוגמה.
אישור הדומיינים של SSL לשימוש עם Maps JavaScript API
למה זה חשוב: כשמשתמשים ב-API של JavaScript של מפות Google עם דומיין SSL, חשוב מאוד לאשר באופן מפורש את הדומיינים של HTTPS כדי להבטיח שהבקשות שלך לא יידחו. שימו לב
שמתן ההרשאה ל-http://yourdomain.com לא מפעיל באופן אוטומטי
את הגרסה המקבילה של SSL, https://yourdomain.com. אפשר לגלול למטה לקטע Client-ID כדי לבדוק את רשימת הדומיינים המורשים שלך במסוף Cloud. כדי לפתור שגיאות שקשורות לשימוש בממשקי ה-API בצד הלקוח עם דומיין SSL, צריך לבדוק אם אלמנטים כלשהם בדף נטענים על גבי HTTP. כדאי לעיין
במדריך לפתרון בעיות בהרשאה.
בחירת גרסת ה-API המתאימה
למה זה חשוב: לפני פיתוח האפליקציה, חשוב לדעת אילו גרסאות של ממשקי ה-API הוצאו משימוש. אם בוחרים לפתח מול גרסאות של ממשקי ה-API שלא הוצאו משימוש, יחסוך לכם זמן פיתוח והוצאות בהמשך הדרך, לאחר שגרסאות שהוצאו משימוש לא יהיו זמינות.
באופן ספציפי, חשוב מאוד להבין את סכימת ניהול הגרסאות שמשמשת את Maps JavaScript API, כדי להימנע משימוש בטעות בגרסה לא מתאימה של ה-API בסביבה שבה אתם פועלים.
לדוגמה, ייתכן שהיא מתאימה לשימוש בגרסה הניסיונית של ה-API בסביבת הפיתוח או הבדיקה, אבל מאוד לא מומלץ להשתמש בה בסביבת ייצור. הסכם רמת השירות חל רק על גרסאות יציבות של ה-API, לכן יש להשתמש רק בגרסאות יציבות בסביבת הייצור שלכם.
מומלץ לעיין במדריך לגרסאות של Maps JavaScript API.
בחירה בין עיצוב בצד הלקוח לצד השרת
למה זה חשוב: בחירת הגישה בצד הלקוח או בצד השרת היא החלטה ארכיטקטונית, והיא חיונית ביותר ליציבות וליכולת ההתאמה של האפליקציה שלכם. בגדול, צריך להשתמש בגישה בצד השרת כדי לבצע עיבוד של רשומות לפני ואחרי העיבוד של רשומות אופליין (כלומר, מחוץ לאפליקציה). לחלופין, צריך להשתמש בגישה מצד הלקוח לגבי חלקים באפליקציות שמקיימים אינטראקציה עם המשתמשים (כלומר, עיבוד בקשות שנשלחו על ידי משתמשים בזמן אמת).
הסיבה העיקרית לחריגה ממכסות היא פריסת גישה בצד השרת, שנדרשת גישה לצד הלקוח, וכתוצאה מכך לאפליקציות לא תקינות. מומלץ מאוד להתייעץ עם אסטרטגיות הקידוד הגיאוגרפי לפני שמתכננים או מפעילים אפליקציות שמסתמכות על קריאות בצד השרת.
ניצול אופטימלי של המכסות
למה זה חשוב: הבנת האופן שבו האפליקציה שלכם מנצלת את המכסה, שנקראת 'זיכויים בממשקי API של מפות', עוזרת להפחית את הסכום שאתם משלמים. לדוגמה, אם אתם משתמשים ב-Maps JavaScript API, האפליקציה שלכם תקבל קרדיטים לכל טעינת מפה. מומלץ לעיין במדריך לתעריפים ולמגבלות של תוכנית Premium.
ניהול השימוש במכסה של שירותי האינטרנט
לפני שמפעילים את השירות, חשוב להבין את השגיאות השונות שקשורות למכסה (לדוגמה, OVER_QUERY_LIMIT או User Rate Limit
Exceeded) ולהגדיר את הלוגיקה המתאימה באפליקציה כדי להגיב לשגיאות כאלה כשחורגים מהמכסה. ראשית, כדאי לקרוא את
השאלות הנפוצות בנושא מגבלות שימוש.
למידע נוסף על קודי הסטטוס שמוחזרים על ידי כל API, ניתן לעיין במדריך למפתחים של אותו API. לדוגמה, אפשר להיעזר במדריך לקודי סטטוס של Directions API.
הבנה והטמעה של המושגים האלה יפחיתו באופן משמעותי את הסיכויים שהאפליקציה תחרוג מהמכסה המותרת, תיחסם על ידי Google ו/או תקלקל.
ביצוע בדיקת טעינה של האפליקציה
למה זה חשוב: השתמשו בבדיקת עומס של האפליקציה כדי לוודא שהיא יכולה לטפל בנפחים גדולים של בקשות, בלי לחרוג מהמכסות שלכם לממשקי ה-API של מפות Google.
הפלטפורמה של מפות Google יכולה להתמודד עם נפחי תנועה גדולים מאוד, אבל בדיקות מול שירותי Google בזמן אמת יובילו לכך שהאפליקציה שלך תחרוג מהמכסה המותרת וייתכן ש-Google תחסום אותה. כמו כן, אתם אחראים לחיובי השימוש שנובעים מבדיקת עומסים.
במקום זאת, בדיקת הטעינה של האפליקציה צריכה לוודא שהאפליקציה שלך יכולה להתמודד עם כמויות גדולות של בקשות, בלי לחרוג מהמכסות שלך לממשקי ה-API של מפות Google או להיחסם על ידי Google. כדי להשיג זאת בבטחה, ניתן לבצע בדיקת טעינה מול API (מזויף) מדומה — שירות שיכול לספוג כמויות גדולות של בקשות — ולהשיב לבקשות עם תגובות חוקיות, בלי להשתמש בפלטפורמה של מפות Google. דוגמה: אם המכסה שלך ב-Geocoding API היא 20 QPS (שאילתות לשנייה), בדיקת הטעינה של האפליקציה צריכה לוודא שהאפליקציה יכולה לטפל ב-600 QPS בלי לשלוח יותר מ-20 QPS ל-Geocoding API.
אם יש לך כוונה לבצע בדיקות טעינה משמעותיות, עליך ליצור קשר עם התמיכה של Google כדי לקבל הנחיות ולוודא ש-Google מודעת לכך.