במדריך הזה מתוארות כמה אסטרטגיות לאופטימיזציה של השימוש בממשקי ה-API של מפות Google מבחינת אבטחה, ביצועים וצריכה.
אבטחה
בדיקת שיטות מומלצות לאבטחה
מפתחות API הם פרטי כניסה שמתמקדים בפרויקט, עם אותם אמצעי זהירות כמו מזהי משתמשים וסיסמאות. מומלץ לקרוא את השיטות המומלצות לאבטחת API כדי להגן על המפתחות שלכם מפני שימוש לא מכוון, שעלול להוביל לשימוש מיותר במכסה ולחיובים לא צפויים בחשבון שלכם.
שימוש במפתחות API לגישה לממשקי API של מפות Google
מפתחות API הם שיטת האימות המועדפת לגישה לממשקי API של מפות Google. נכון לעכשיו, השימוש במזהי הלקוח עדיין נתמך, אבל מפתחות ה-API תומכים באמצעי בקרת אבטחה מפורטים יותר ואפשר לכוונן אותם כך שהם יפעלו עם כתובות אינטרנט, כתובות IP וערכות SDK ספציפיות לנייד (Android ו-iOS). מידע על יצירה ואבטחה של מפתח API זמין בדף 'שימוש במפתח API' לכל API או SDK. (לדוגמה, ב-JavaScript API של מפות Google, תוכלו להיכנס לדף שימוש במפתח API).
ביצועים
שימוש בהשהיה מעריכית לפני ניסיון חוזר (exponential backoff) כדי לטפל בשגיאות
אם באפליקציות שלכם מופיעות שגיאות עקב ניסיונות מוגזמים לקרוא ל-API בתוך פרק זמן קצר, כמו שגיאות QPS, כדאי להשתמש בהשהיה מעריכית לפני ניסיון חוזר (exponential backoff) כדי לאפשר את עיבוד הבקשות.
השהיה מעריכית לפני ניסיון חוזר (exponential backoff) היא שימושית ביותר לשגיאות במאות ה-500. למידע נוסף, ראו טיפול בקודי סטטוס של החזרת HTTP.
ספציפית, כדאי להתאים את קצב השאילתות. בקוד שלכם, מוסיפים תקופת המתנה של S שניות בין השאילתות. אם השאילתה עדיין מובילה לשגיאת QPS, כדאי להכפיל את תקופת ההמתנה ואז לשלוח שאילתה נוספת. ממשיכים בהתאמה של תקופת ההמתנה עד שהשאילתה חוזרת ללא שגיאה.
שליחת בקשות לאינטראקציה של משתמשים על פי דרישה
יש לשלוח בקשות לממשקי API שכוללות אינטראקציה עם משתמשים רק על פי דרישה.
כלומר, צריך להמתין שמשתמש הקצה יבצע פעולה (כמו on-click) כדי ליזום את בקשת ה-API, ולאחר מכן משתמשים בתוצאות כדי לטעון מפה, להגדיר יעד או להציג מידע מתאים. גישה על פי דרישה מונעת בקשות מיותרות לממשקי ה-API ומפחיתה את צריכת ה-API.
הימנעות מהצגת תוכן שכבת-על כשהמפה זזה
להימנע משימוש ב-Draw() כדי להציג תוכן שכבת-על מותאם אישית במפה בזמן שהמשתמש עשוי להזיז את המפה. מכיוון שהמפה משורטטת מחדש בכל פעם שמשתמש מזיז את המפה, הצבת תוכן שכבת-על במפה בו-זמנית עלולה ליצור עיכובים או שיבושים חזותיים. הוסיפו או מסירים תוכן שכבת-על מהמפה רק לאחר שהמשתמש מפסיק להזיז את התצוגה או לשנות את מרחק התצוגה.
הימנעות מפעולות אינטנסיביות בשיטות של Draw
באופן כללי, מומלץ להימנע מפעולות שאינן אינטנסיביות בעבודה באמצעות method Draw(). לדוגמה, כדאי להימנע מהפעולות הבאות בקוד ה-method של Draw():
- שאילתות שמחזירות כמות גדולה של תוכן.
- שינויים רבים בנתונים המוצגים.
- מניפולציה של רכיבים רבים של מודל אובייקטי מסמך (DOM).
הפעולות האלה עלולות להאט את הביצועים וליצור עיכובים או שיבושים חזותיים בזמן עיבוד המפה.
שימוש בתמונות רשת נקודות לסמנים
כשמוסיפים סמנים כדי לזהות מיקום במפה, מומלץ להשתמש בתמונות רשת נקודות, כמו תמונות בפורמט PNG. או JPG. מומלץ להימנע משימוש בתמונות Scalable Vector Graphics (SVG), כי עיבוד תמונות SVG עלול לגרום לעיכוב כשמציירים מחדש את המפה.
אופטימיזציה של סמנים
האופטימיזציה משפרת את הביצועים על ידי עיבוד של סמנים רבים כאל רכיב סטטי אחד. האפשרות הזו שימושית במקרים שבהם נדרש מספר גדול של סמנים. כברירת מחדל, API של JavaScript במפות Google יחליט אם תתבצע אופטימיזציה של סמן. כשיש הרבה סמנים, Maps JavaScript API ינסה לעבד סמנים עם אופטימיזציה. לא כל הסמנים ניתנים לאופטימיזציה. במצבים מסוימים, ייתכן ש-API JavaScript של מפות Google יצטרך לעבד סמנים ללא אופטימיזציה. השבתת הרינדור האופטימלי של קובצי GIF או PNG מונפשים, או כשצריך לעבד כל סמן כרכיב DOM נפרד.
יצירת אשכולות לניהול תצוגת הסמנים
כדי לנהל את התצוגה של הסמנים לזיהוי מיקומים במפה, אפשר ליצור אשכול סמנים באמצעות הספרייה Marker Clusterer. הספרייה 'מאשכול סמנים' כוללת אפשרויות עבור:
- גודל הרשת, כדי לציין את מספר הסמנים שצריך לקבץ באשכול.
- זום מקסימלי כדי לציין את רמת הזום המקסימלית שבה יוצג האשכול.
- נתיבי תמונות, לשימוש בתמונות הגרפיקה כסמלים של סמנים.
צריכה
כדי לתכנן את התקציב ולשלוט בעלויות, מבצעים את הפעולות הבאות:
- מגדירים התראת תקציב כדי לעקוב אחרי הגידול של העלויות ביחס לסכום מסוים. הגדרת תקציב לא מגבילה את השימוש ב-API, אלא רק כשהעלויות מתקרבות לסכום שצוין.
- להגביל את השימוש היומי ב-API כדי לנהל את העלויות של ממשקי API שניתנים לחיוב. הגדרת מגבלות לבקשות ליום מאפשרת להגביל את העלויות. משתמשים במשוואה פשוטה כדי לקבוע את המכסה היומית, בהתאם לסכום שרוצים להוציא: (עלות חודשית/מחיר לכל) חלקי 30 = מכסה ליום (ל-API אחד). ההטמעה הספציפית עשויה להשתמש במספר ממשקי API שניתנים לחיוב, לכן עליכם להתאים את המשוואה לפי הצורך. אתם יכולים לקבל קרדיט בסך 200 דולר ארה"ב ל-Google Maps API בכל חודש, ואתם צריכים לקחת את זה בחשבון בחישובים.
- ניתן להשתמש בפרויקטים מרובים כדי לבודד את השימוש, לתעדף אותו ולעקוב אחריו. לדוגמה, נניח שאתם משתמשים באופן קבוע בממשקי ה-API של הפלטפורמה של מפות Google בבדיקות שלכם. כשיוצרים פרויקט נפרד לבדיקה, עם מכסות ומפתחות API משלו, אפשר לבצע בדיקות יסודיות ולהימנע מהוצאות יתר על המידה.
ניהול הצריכה במפות Google
הצגת מפה אחת בכל דף היא דרך טובה לבצע אופטימיזציה של תצוגת מפות, מכיוון שבאופן כללי משתמשים מקיימים אינטראקציה עם מפה אחת בלבד בכל פעם. האפליקציה יכולה לשנות את המפה כך שיוצגו קבוצות נתונים שונות, בהתאם לאינטראקציה ולצרכים של הלקוחות.
שימוש בתמונות סטטיות
בקשות שמשתמשות בתמונות דינמיות (מפות דינמיות ו-Street View דינמי) עולות יותר מבקשות של מפות סטטיות ו-Street View סטטי. אם אתם לא צופים את האינטראקציה של המשתמשים עם 'מפה' או עם Street View (שינוי מרחק התצוגה או הזזה), השתמשו בגרסאות הסטטיות של ממשקי ה-API האלה.
תמונות ממוזערות - מפות ותמונות קטנות מאוד - הן שימוש טוב נוסף במפות סטטיות וב-Street View סטטי. החיובים עבור הפריטים האלה הם בתעריף נמוך יותר ואחרי האינטראקציה של המשתמש (בלחיצה), והם יכולים להעביר את המשתמשים לגרסה דינמית וליהנות מחוויית שימוש מלאה במפות Google.
שימוש בממשק ה-API של מפות Google להטמעה
תוכלו להשתמש בחינם ב-Maps Embed API כדי להוסיף מפה עם סמן יחיד או מפה דינמית. השתמשו ב-Maps Embed API לאפליקציות שבהן מופיע סמן יחיד ולא נדרשת התאמה אישית של המפה. בקשות להטמעת API של מפות Google, באמצעות מצב 'מסלול', 'מצב תצוגה' או 'חיפוש' יחויבו (פרטים נוספים זמינים בטבלת התמחור).
שימוש בערכות SDK של מפות לנייד עבור אפליקציות לנייד
לאפליקציות לנייד, השתמשו ב-SDK של מפות ל-Android או ב-SDK של מפות ל-iOS בהצגת מפה. השתמשו ב-API הסטטי של מפות Google או ב-JavaScript API של מפות Google כאשר לא ניתן להשתמש בערכות ה-SDK לנייד.
ניהול הצריכה במסלולים
הגבלת נקודות הציון של ה-API של המסלול
כשאפשר, הגבילו את על רשומות המשתמשים בשאילתה לעד 10 ציוני דרך. בקשות שכוללות יותר מ-10 ציוני דרך יחויבו בתעריף גבוה יותר.
שימוש באופטימיזציה של Directions API לניתוב אופטימלי
בקשות שמשתמשות בארגומנט האופטימיזציה של ציון הדרך יחויבו בשיעור גבוה יותר. מידע נוסף זמין במאמר אופטימיזציה של ציוני דרך.
הארגומנט של האופטימיזציה ממיין נקודות ציון כדי להבטיח ניתוב אופטימלי, כלומר, מעבר מ-A ל-E יהיה חוויה טובה יותר בזמן אופטימיזציה (A-B-C-D-E) לעומת רצף אקראי של מסלול לא מותאם (למשל A-D-B-C-E).
שימוש במודלים של תנועה בזמן אמת ב-Directions API וב-Destination Matrix API
עבור בקשות של Directions API ו-Distance Matrix API שכוללות מודלים של תנועה בזמן אמת, החיוב יהיה גבוה יותר.
כדי להפעיל מודלים של תנועה בזמן אמת, צריך להגדיר את שעת היציאה ל-now.
אם מודלים של תנועה לא נכללים בבקשה, התוצאות יתבססו רק על גורמים פיזיים: כבישים, מרחק ומהירות מהירות.
שימוש במסלול הנסיעה ובכביש הקרוב ביותר כאשר נתוני ה-GPS לא מדויקים
התכונות של Maps Roads API, Route Traveled ו-Nearest Road, כלולות ברמה המתקדמת ומחויבות בתעריף גבוה יותר. כדאי להשתמש בתכונות האלה כאשר נתוני ה-GPS לא מדויקים, ו-Roads API יכול לעזור לקבוע את הדרך הנכונה. מגבלות מהירות, תכונה נוספת של Roads API, זמינה רק ללקוחות של מעקב אחר נכסים.
מגבלת מהירות הדגימה במיקומים של 5 עד 15 דקות
כדי לצמצם את כמות הקריאות לשירות Maps Roads API, כדאי לדגום את מיקומי הנכסים במרווחי זמן של 5 עד 15 דקות. הערך המדויק תלוי במהירות שבה הנכס נע. אם הנכס הוא נייח, מספיק דגימת מיקום אחת. אין צורך לבצע מספר שיחות.
כדי לצמצם את זמן האחזור הכולל, כדאי להפעיל את שירות Speed Limit אחרי שצוברים נתונים במקום לשלוח קריאה ל-API בכל פעם שמתקבל מיקום של נכס לנייד.
ניהול הצריכה במקומות
אופטימיזציה של הטמעות השלמה אוטומטית לגבי מקומות
כדי לייעל את עלות השימוש בהשלמה האוטומטית של המקום:
להשתמש במסכות של שדות בווידג'טים של השלמה אוטומטית ב-JavaScript, ב-Android וב-iOS כדי להחזיר רק את השדות של נתוני המקום הנחוצים.
אפשרויות החיוב שתבחרו תלויות בתרחיש לדוגמה שלכם. בהתאם לאופן שבו ההטמעה שלכם משתמשת בסשנים של Autcomplete או לא, תחויבו במק"טים של השלמה אוטומטית – לפי בקשה או השלמה אוטומטית – לכל סשן.
לקבלת מידע נוסף והדרכה לבחירת האפשרות המתאימה לתרחיש שלכם לדוגמה, ראו שיטות מומלצות לאופטימיזציה של עלויות באמצעות השלמה אוטומטית.
החזרת נתונים עבור שדות ספציפיים ב'פרטי מקום' ובבקשות ל'חיפוש מקום'
אפשר להתאים אישית בקשות של 'פרטי מקום' ו'חיפוש מקום' כדי להחזיר נתונים לשדות ספציפיים שבהם נעשה שימוש באפליקציה. השדות האלה מחולקים לקטגוריות: בסיסי, יצירת קשר ו-אטמוספרה. בקשות שלא כוללות שדות כלשהם יקבלו נתונים על כל השדות.
החיוב של בקשות לפרטי מקום מבוסס על הסוגים והכמויות של הנתונים המבוקשים. בקשות שלא צוינו בהן שדות כלשהם יחויבו בתעריף המלא. למידע נוסף, ראה פרטי מקום וחיפוש מקום.
הוזלת עלויות באמצעות Geocoding API
אם האפליקציה שלכם מטפלת בכתובות מסוג משתמש, לפעמים הכתובות לא חד-משמעיות (חסרות, באיות שגוי או שהפורמט שלהן שגוי). ניתן להבדיל בין כתובות באמצעות השלמה אוטומטית, ואז להשתמש במזהי המקומות כדי לקבל את מיקומי המקומות.
עם זאת, אם יש לכם כתובת מדויקת (או קרוב אליה), תוכלו לצמצם את העלויות באמצעות קידוד גיאוגרפי במקום השלמה אוטומטית. למידע נוסף, ראו שיטות מומלצות לקידוד גיאוגרפי של כתובות.
איך פועלות המכסות בפלטפורמה של מפות Google
בכל ממשקי ה-API שלנו יש מגבלות על מספר הקריאות שכל לקוח יכול לבצע. המכסות האלה מוגדרות לפי דקה. ברגע שתגיעו למכסת הקריאות ב-API מסוים תוך דקה, לא יתקבלו קריאות עתידיות עד לדקה הבאה.
רק בקשות ובקשות שבוצעו בהצלחה וגורמות לשגיאות בחיבור לשרת נספרות כחלק מהמכסה. בקשות שנכשלו באימות לא נכללות במכסה.
בחלק מממשקי ה-API של מפות Google יש אכיפה לשנייה בנוסף לאכיפת המכסה לדקה. האכיפה הזו לשנייה לא מבטיחה שימוש אחיד לאורך כל הדקה, ולא תמנע מכם להגיע למכסת השימוש באותה דקה. היא מונעת ניצול של כל המכסה בשנייה או בשנייה הראשונה בכל דקה נתונה, ומגינה מפני שיבושים בשירות במקרה של עלייה פתאומית בשימוש. כדי להתמודד עם ההבדלים האלה באכיפה, כדאי לתכנן את השימוש במכסות ואת הדרישות באמצעות חישוב הממוצע של השימוש ב-QPM לכל ה-QPS.
ממשקי ה-API של GMP עם האכיפה הזו לשנייה הם Directions API, Distance Matrix API, עזר גובה, Geocoding API, Places API ו-Roads API.