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