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