רשימת משימות לפני ההשקה

איפה מנהלים את Client-ID במסוף Google Cloud

פונקציית הניהול של מזהי הלקוח בתוכנית Premium זמינה ב מסוף Cloud בחלק התחתון של הדף 'פרטי כניסה לפלטפורמה של מפות Google', בקטע Client ID.

האזור החדש Client ID בדף Credentials

משימות נוספות של ניהול מזהי לקוח, כולל הרשאת כתובת URL וסוד חתימה על מזהה לקוח לניהול קטגוריות, לדף Client ID, על ידי לחיצה על עריכה בקצה הימני של הקטע Client ID.

חשוב: תוכנית הפרימיום של הפלטפורמה של מפות Google כבר לא זמינה עבור נרשמים או לקוחות חדשים.

מוודאים שלצוות יש גישה למשאבים הנדרשים

שימוש במסוף Google Cloud

למה זה חשוב: מסוף Google Cloud מעניק לך גישה למידע כמו דוחות שימוש, פידים של חדשות ומשאבים למפתחים. וחשוב יותר, מסוף Cloud מאפשר לך לשלוח בקשות תמיכה באמצעות הפלטפורמה של מפות Google צוות התמיכה אם נתקלת בבעיות טכניות במהלך הפיתוח או ההשקה.

לפני ההשקה, צריך להפעיל גישה למסוף Cloud לכל המפתחים שאחראים על תחזוקת האפליקציה. אם המיקום אם תיתקלו בבעיות טכניות, הגישה למסוף Cloud תאפשר לחברים בצוות שלכם לפנות לתמיכה וגם לאפשר לצוות התמיכה שלנו ליצור קשר עם בעלי העניין המתאימים של הארגון. לדוגמה, ייתכן שצוות התמיכה יצטרך ליצור קשר עם של הארגון אם נזהה תנועה חריגה או התנהגות חריגה שעלולה להוביל כדי לפצל את האפליקציה. הבטחה שנוכל ליצור קשר עם הגורמים המתאימים מפתחים יכולים להפיק את ההבדל בין הפסקה זמנית בשירות בלתי צפויה ומניעת הפסקה זמנית בשירות.

הרשמה לקבלת התראות באימייל לקבוצות

למה זה חשוב: כדי להתעדכן בהתפתחויות ושינויים בכל ממשקי ה-API של מפות Google, אנחנו ממליצים להירשם לאחד או יותר מקבוצות האימייל הבאות:

  • google-maps-platform-notifications – עדכונים טכניים בנושא שירותי האינטרנט וממשקי ה-API של הפלטפורמה של מפות Google, התראות על הפסקות זמניות בשירות והודעות על תכונות הפלטפורמה (כ-3-5 הודעות בחודש).
  • google-maps-js-api-v3-notify – גרסאות חדשות של Google Maps JavaScript API (כ-4 הודעות בשנה).

אופטימיזציה של האפליקציה

צריך להגדיר חומת אש כדי לאפשר גישה לפלטפורמה של מפות Google Services (שירותים)

למה זה חשוב: שירותי הפלטפורמה של מפות Google משתמשים במגוון רחב מתוך דומיינים, שחלקם לא שייכים ל*google.com דומיין. אם אתה נמצא מאחורי חומת אש מגבילה, חשוב לאפשר גישה הדומיינים שמשמשים את כל שירות API של מפות Google. אם חומת האש לא מאפשרת גישה לדומיינים האלה, בקשות API ייכשלו, ויכול להיות שהאפליקציות שלכם יפסיקו לפעול. צפייה הרשימה המלאה של הדומיינים שבהם משתמשים ממשקי API של מפות Google.

אנחנו לא ממליצים לנהל הגבלות של חומת אש באמצעות מכיוון שכתובות ה-IP שמשויכות לדומיינים האלה אינן סטטיות.

הערה: שירותי הפלטפורמה של מפות Google משתמשים ביציאה 80 (http) ו-443 (https) עבור תנועה נכנסת ותנועה יוצאת. לשירותים האלה נדרשים גם GET, POST, PUT, DELETE וגם בקשות HEAD. הגדרת חומת האש כדי לאפשר תנועה ביציאות האלה ולאפשר בהתאם ל-API ולתרחיש לדוגמה.

נותנים לדומיינים האלה הרשאה להשתמש עם API של מפות Google ל-JavaScript

למה זה חשוב: בעת שימוש ב-API JavaScript של מפות Google עם דומיין SSL, חשוב מאוד מורשה הדומיינים שלך ב-HTTPS כדי לוודא שהבקשות לא יידחו. הערה שההרשאה http://yourdomain.com לא מעניקה הרשאה אוטומטית להפעיל את הערך המקביל של SSL, https://yourdomain.com. לבדיקה את הרשימה של הדומיינים המורשים מסוף Cloud על ידי גלילה למטה אל בקטע Client ID. כדי לפתור שגיאות שקשורות לשימוש בממשקי ה-API בצד הלקוח עם דומיין SSL, לבדוק אם רכיבים כלשהם בדף נטענים ב-HTTP. תצוגה מפורטת את המדריך לפתרון בעיות בהרשאות.

בחירת גרסת ה-API המתאימה

למה זה חשוב: לפני פיתוח האפליקציה, חשוב לדעת אילו גרסאות של ממשקי ה-API הוצאו משימוש. בחירה לפתח מול גרסאות של ממשקי ה-API שלא הוצאו משימוש, ואת זמן הפיתוח והעלות בהמשך, ברגע שגרסאות שהוצאו משימוש לא זמין.

במיוחד, חשוב להבין את סכמת ניהול הגרסאות שבה משתמשים API JavaScript של מפות Google, כדי להימנע משתמשים בטעות בגרסה לא מתאימה של ה-API בסביבה שלכם.

לדוגמה, ייתכן שמתאים לשימוש במודל ניסיוני של ה-API בסביבת הפיתוח או הבדיקה, אבל לא מומלץ להשתמש בגרסה הניסיונית בסביבת ייצור. הסכם רמת השירות שלנו חל רק על גרסאות יציבות של ה-API, ולכן עליך להשתמש רק יציבות בסביבת הייצור.

אפשר לעיין במדריך לגבי API של מפות Google ל-JavaScript גרסאות שונות.

בחירה בין עיצוב בצד הלקוח לעיצוב בצד השרת

למה זה חשוב: בחירה בצד הלקוח או בצד השרת היא החלטה ארכיטקטונית והיא חיונית לחלוטין היציבות והמדרגיות של האפליקציה. בגדול, בצד השרת צריך להשתמש בגישה לעיבוד של רשומות אופליין לפני ואחרי (כלומר, מחוץ לאפליקציה). לחלופין, גישה בצד הלקוח צריך לשמש בחלקים של האפליקציות שיוצרים אינטראקציה עם המשתמשים שלכם (כלומר, לעבד בזמן אמת בקשות שנשלחו על ידי משתמשים).

פריסת גישה בצד השרת שבה גישה בצד הלקוח כי שימוש אחר הוא הסיבה העיקרית לחריגה מהמכסות, וכתוצאה מכך יישומים מנותקים. מומלץ מאוד לעיין קידוד גיאוגרפי לפני פיתוח או השקה של אפליקציות שמתבססות על קריאות בצד השרת.

אופטימיזציה של ניצול המכסות

למה זה חשוב: הבנת האופן שבו האפליקציה שלך צורכת מכסה, שנקראת מפות Google APIs, עוזרת להפחית את הסכום שמשלמים. עבור לדוגמה, אם אתם משתמשים ב-Maps JavaScript API, האפליקציה צריכה קרדיטים לממשקי API של מפות Google טעינת מפה. אפשר לעיין במדריך לגבי תוכנית פרימיום מגבלות ושיעורי שימוש.

ניהול השימוש במכסות לשירותי אינטרנט

לפני השקת השירות, חשוב שתבינו את שגיאות שונות שקשורות למכסות (לדוגמה OVER_QUERY_LIMIT, User Rate Limit Exceeded) ולהגדיר את הלוגיקה המתאימה באפליקציה. כדי להגיב לשגיאות כאלה אם תחרגו מהמכסה. עליך להתחיל בקריאה שאלות נפוצות בנושא מגבלות שימוש לקבלת מידע על קודי הסטטוס שהוחזרו על ידי כל API, אפשר לעיין במדריך למפתחים לאותו ממשק API. לדוגמה, אפשר לעיין במדריך קודי הסטטוס של ה-API של הנחיות. הבנה ויישום של המושגים האלה יפחיתו משמעותית את הסיכויים של האפליקציה חורגות מהמכסה המותרת שלה, נחסמות על ידי Google, ו/או לשבור.

ביצוע בדיקת עומס על האפליקציה

למה זה חשוב: שימוש בבדיקת עומסים של האפליקציה כדי לוודא הוא יכול לטפל בכמויות גדולות של בקשות מבלי לחרוג מהמכסות שלכם ממשקי API של מפות Google.

הפלטפורמה של מפות Google יכולה להתמודד עם נפחי תנועה גבוהים מאוד, אבל מתבצעת בדיקה מול נתונים בזמן אמת שירותי Google יובילו לחריגה מהמכסה המותרת של האפליקציה שלך, נחסמו על ידי Google. אתה גם אחראי לחיובי שימוש הנובעים מבדיקת העומס.

במקום זאת, בדיקת הטעינה של האפליקציה אמורה לוודא שהאפליקציה יכולה להתמודד עם כמויות גדולות של בקשות מבלי לחרוג מהמכסות שלכם לממשקי API של מפות Google, נחסמו על ידי Google. כדי לעשות זאת בצורה בטוחה, צריך לבצע בדיקת עומסים על מודל מדומה (זיוף) API – שירות שיכול לסבול כמויות גדולות של בקשות – ולהגיב בקשות עם תשובות תקינות, בלי לערב את הפלטפורמה של מפות Google. דוגמה: אם המכסה של Geocoding API היא 3000 QPM (שאילתות לדקה), בדיקת העומס של האפליקציה אמורה להבטיח שהאפליקציה יכולה לטפל בנפח הרבה יותר גבוה, כמו 90000 QPM, שולחים יותר מ- 3,000 QPM ל-Geocoding API.

אם אתם מתכננים לבצע בדיקות עומסים משמעותיות, צריך ליצור קשר התמיכה של Google כדי לקבל הדרכה, וכדי לוודא ש-Google מודעת לכך של הבדיקות המתוכננות.