במדריך הזה מתוארות כמה אסטרטגיות לביצוע אופטימיזציה של השימוש בממשקי ה-API של מפות Google מבחינת אבטחה, ביצועים וצריכה.
אבטחה
עיון בשיטות המומלצות לאבטחה
מפתחות API הם פרטי כניסה ספציפיים לפרויקטים, שדורשים את אותם אמצעי הזהירות כמו מזהי משתמשים וסיסמאות. כדאי לעיין בשיטות המומלצות לאבטחת API כדי לאבטח את המפתחות מפני שימוש לא מכוון, שעלול להוביל לשימוש לא נכון במכסה ולחיובים בלתי צפויים בחשבון שלכם.
שימוש במפתחות API לגישה לממשקי API של מפות Google
מפתחות API הם שיטת האימות המועדפת לגישה לממשקי API של מפות Google API. אמנם השימוש במזהי הלקוח עדיין נתמך, אבל מפתחות 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(). לדוגמה, יש להימנע מהפעולות הבאות בקוד ה-method של Draw():
- שאילתות שמחזירה כמות גדולה של תוכן.
- שינויים רבים בנתונים המוצגים.
- ביצוע מניפולציות על רכיבים רבים של מודל אובייקטים של מסמכים (DOM).
הפעולות האלה עלולות להאט את הביצועים ולהוביל לעיכוב או שיבושים חזותיים במהלך העיבוד של המפה.
שימוש בתמונות רשת נקודות לסמנים
כשמוסיפים סמנים, צריך להשתמש בתמונות בפורמט רשת נקודות, כמו תמונות בפורמט PNG. או JPG. מומלץ להימנע משימוש בתמונות Scalable Vector Graphics (SVG), כי העיבוד של תמונות SVG עלול לגרום לעיכובים בעת שרטוט מחדש של המפה.
אופטימיזציה של הסמנים
האופטימיזציה משפרת את הביצועים על ידי רינדור של סמנים רבים כרכיב סטטי אחד. האפשרות הזו שימושית במקרים שבהם יש צורך במספר גדול של סמנים. כברירת מחדל, ה-API של JavaScript במפות Google יקבע אם לבצע אופטימיזציה של סמן. כשיש הרבה סמנים, הממשק Maps JavaScript API ינסה לעבד את הסמנים באמצעות אופטימיזציה. לא ניתן לבצע אופטימיזציה לכל הסמנים. במצבים מסוימים, ה-API של JavaScript של מפות Google עשוי לעבד את הסמנים ללא אופטימיזציה. משביתים את האופטימיזציה של קובצי GIF או PNG מונפשים, או כשצריך לעבד כל סמן כרכיב DOM נפרד.
יצירת אשכולות לניהול תצוגת הסמנים
כדי לנהל את תצוגת הסמנים לזיהוי מיקומים במפה, צור אשכול סמנים באמצעות הספרייה אשכול הסמנים. ספריית אשכול הסמן כוללת אפשרויות עבור:
- גודל רשת, כדי לציין את מספר הסמנים שיקובצו באשכול.
- זום מקסימלי, כדי לציין את רמת הזום המקסימלית שבה תוצג האשכול.
- נתיבי תמונות, עבור התמונות הגרפיות לשימוש כסמלים של סמנים.
צריכה
כדי לתכנן את התקציב ולשלוט בעלויות, יש לבצע את הפעולות הבאות:
- הגדירו התראת תקציב כדי לעקוב אחר העלויות גדלות לקראת סכום מסוים. הגדרת התקציב לא מגבילה את השימוש ב-API, אלא רק כשהעלויות מתקרבות לסכום שציינתם.
- הגבילו את השימוש היומי ב-API כדי לנהל את העלויות של ממשקי API לחיוב. כדי להגביל את העלויות, אפשר להגדיר מכסות לבקשות ליום. משתמשים במשוואה פשוטה כדי לקבוע את המכסה היומית, בהתאם לסכום שרוצים להוציא: (עלות חודשית/מחיר לכל )/30 = מכסה יומית (לממשק API אחד). בהטמעה הספציפית שלכם ייתכן שייעשה שימוש בכמה ממשקי API שניתנים לחיוב, ולכן עליכם לשנות את המשוואה לפי הצורך. בכל חודש מקבלים זיכוי של 200$USD לממשקי Google Maps API, ולכן צריך להביא זאת בחשבון בחישובים.
- אתם יכולים להשתמש במספר פרויקטים כדי לבודד את השימוש, לתעדף אותו ולעקוב אחריו. לדוגמה, נניח שאתם משתמשים באופן קבוע בממשקי ה-API של הפלטפורמה של מפות Google בבדיקות. אפשר ליצור פרויקט נפרד לבדיקה, עם מכסות ומפתחות API משלו, כדי לבצע בדיקות קפדניות ולהימנע מהוצאות מיותרות.
ניהול הצריכה במפות Google
שימוש במפה אחת בכל דף הוא דרך טובה לאופטימיזציה של תצוגת המפות, כי בדרך כלל המשתמשים יוצרים אינטראקציה עם מפה אחת בלבד בכל פעם. האפליקציה יכולה לשנות את המפה כדי להציג קבוצות נתונים שונות, בהתאם לאינטראקציה ולצרכים של הלקוח.
שימוש בתמונות סטטיות
בקשות שבהן נעשה שימוש בתמונות דינמיות (מפות דינמיות ו-Street View דינמי) עולות יותר מאשר מפות סטטיות ו-Street View סטטי. אם אתם לא צופים אינטראקציה של משתמשים עם המפה או עם Street View (שינוי מרחק התצוגה או הזזת המצלמה), כדאי להשתמש בגרסאות הסטטיות של ממשקי ה-API האלה.
תמונות ממוזערות, שהן מפות ותמונות קטנות מאוד, הן עוד שימוש יעיל במפות סטטיות וב-Street View סטטי. הפריטים האלה מחויבים בתעריף נמוך יותר ולאחר אינטראקציה של המשתמש (בלחיצה), והם יכולים להעביר משתמשים לגרסה דינמית כדי ליהנות מחוויה מלאה במפות Google.
שימוש ב-API של מפות Google להטמעה
ניתן להשתמש ב- Maps Embed API כדי להוסיף מפה עם סמן יחיד או מפה דינמית, בחינם. שימוש ב-API של מפות Google להטמעה באפליקציות שבהן צריך לסמן סמן יחיד ולא להתאים אישית את המפה. נחייב בקשות של Maps Embed API שמשתמשות במצב מסלול, במצב תצוגה או במצב חיפוש (לפרטים נוספים, עיינו בטבלת התמחור).
שימוש בערכות SDK של מפות לנייד עבור אפליקציות לנייד
עבור אפליקציות לנייד, בעת הצגת מפה השתמשו ב-SDK של מפות Google ל-Android או ב-SDK של מפות Google ל-iOS. להשתמש ב- Maps Static API או ב-API של JavaScript במפות Google כשאין צורך להשתמש בערכות SDK לנייד.
ניהול הצריכה במסלולים
הגבלת ציוני דרך ב-Directions API
אם הדבר אפשרי, מגבילים את ערכי המשתמשים בשאילתה ל-10 ציוני דרך לכל היותר. בקשות שכוללות יותר מ-10 ציוני דרך מחויבות בתעריף גבוה יותר.
שימוש באופטימיזציה של Directions API להשגת ניתוב אופטימלי
בקשות שמשתמשות בארגומנט האופטימיזציה של נקודת הציון מחויבות בתעריף גבוה יותר. מידע נוסף זמין במאמר ציוני דרך ב-Optimize.
ארגומנט האופטימיזציה ממיין ציוני דרך כדי להבטיח ניתוב אופטימלי, כלומר, כשנוסעים מ-A ל-E נהנים מחוויה טובה יותר (A-B-C-D-E) לעומת הרצף האקראי של מסלול לא אופטימלי (למשל A-D-B-C-E).
שימוש במודלים של תנועת גולשים בזמן אמת ב-Directions API וב-Duration Matrix API
עבור בקשות של Directions API ושל טווח מטריקס API, שכוללות מודלים של תנועה בזמן אמת, החיוב מתבצע בתעריף גבוה יותר.
כדי להפעיל מודלים של תנועה בזמן אמת, זמן היציאה הוא now.
אם המודלים של התנועה מושמטים מהבקשה, התוצאות מבוססות אך ורק על גורמים פיזיים: כבישים, מרחק ומגבלות מהירות.
שימוש במסלול הנסיעה והכביש הקרוב ביותר כשנתוני ה-GPS לא מדויקים
התכונות של Maps Roads API, 'מסלול הנסיעה' ו'הכביש הקרוב ביותר', כלולות ברמה המתקדמת והחיוב שלהן מתבצע בתעריף גבוה יותר. כדאי להשתמש בתכונות האלה כאשר נתוני ה-GPS לא מדויקים ו-Roads API יכול לעזור לקבוע את הכביש הנכון. המאפיין 'מגבלות מהירות' הוא תכונה נוספת של Roads API, שזמינה רק ללקוחות של מעקב אחר נכסים.
מיקומים של מגבלות מהירות דגימה במרווחי זמן של 5 עד 15 דקות
כדי לצמצם את נפח הקריאות להגבלת המהירות ב- Maps Roads API, כדאי לדגום את המיקומים של הנכסים במרווחים של 5 עד 15 דקות. הערך המדויק תלוי במהירות שבה הנכס מתקדם. אם הנכס נשאר נייח, מספיק להשתמש בדגימה אחת של מיקום. אין צורך לבצע מספר שיחות.
כדי לקצר את זמן האחזור הכולל, כדאי לקרוא לשירות הגבלת המהירות אחרי שצוברים נתונים, במקום להפעיל את ה-API בכל פעם שמתקבל מיקום של נכס לנייד.
ניהול הצריכה ב'מקומות'
אופטימיזציה של הטמעות השלמה אוטומטית של מקומות
כדי למזער את עלות השימוש בהשלמה האוטומטית של מקומות:
להשתמש במסכות של שדות בווידג'טים של השלמה אוטומטית ב-JavaScript, Android ו-iOS, כדי להחזיר רק את השדות של נתוני המקום שדרושים לכם.
בחירת אפשרויות חיוב בהתאם לתרחיש לדוגמה שלך. בהתאם לסוג ההטמעה שלכם, אם בהטמעה נעשה שימוש בסשנים של Autcomplete או לא, נחייב אתכם במק"טים מסוג השלמה אוטומטית – לפי בקשה או השלמה אוטומטית – לכל סשן.
מידע נוסף והנחיות לבחירת האפשרות המתאימה לתרחיש לדוגמה שלכם זמינים במאמר שיטות מומלצות לאופטימיזציה של עלויות עם השלמה אוטומטית של מקום.
החזרת נתונים לשדות ספציפיים בבקשות 'פרטי מקום' ו'חיפוש מקום'
תוכלו להתאים אישית בקשות של 'פרטי מקום' ו'חיפוש מקום' כדי להחזיר נתונים לשדות ספציפיים שבהם השתמשתם באפליקציה. השדות האלה מחולקים לקטגוריות: Basic, Contact ו-Atmosphere. בבקשות שלא מציינים שדות כלשהם, הנתונים מכל השדות יתקבלו.
החיוב על בקשות של פרטי מקום מבוסס על הסוגים והכמויות של הנתונים המבוקשים. בקשות שלא יצוינו שדות יחויבו במחיר המלא. למידע נוסף, ראו פרטי מקום וחיפוש מקום.
צמצום העלויות באמצעות Geocoding API
אם האפליקציה שלכם מטפלת בכתובות מסוג משתמש, לפעמים הכתובות לא ברורות (לא מלאות, שגויות או בפורמט שגוי). ניתן להבדיל בין כתובות באמצעות ההשלמה האוטומטית, ולאחר מכן להשתמש במזהי המקומות כדי לאתר את מיקומי המקומות.
עם זאת, אם יש לכם כתובת מדויקת (או קרובה לה), תוכלו להשתמש בקידוד גיאוגרפי במקום בהשלמה האוטומטית כדי להפחית את העלויות. למידע נוסף, קראו את המאמר שיטות מומלצות לשימוש בכתובות בקידוד גיאוגרפי.
איך פועלות המכסות בפלטפורמה של מפות Google
בכל ממשקי ה-API שלנו יש מגבלות על מספר השיחות שכל לקוח יכול לבצע. המכסות האלה מוגדרות לפי דקה. אחרי שהגעתם למכסת הקריאות ל-API מסוים תוך דקה, לא יתקבלו קריאות עתידיות עד לדקה הבאה.
רק בקשות ובקשות שבוצעו בהצלחה שגורמות לשגיאות בשרת נכללות במכסה. בקשות שנכשלו באימות לא נכללות במכסה.
בחלק מממשקי ה-API של מפות Google מתבצעת אכיפה לשנייה, בנוסף לאכיפה של המכסה לדקה. האכיפה לשנייה לא מבטיחה שימוש אחיד לאורך כל הדקה, וגם לא תמנע מכם להגיע למכסת השימוש באותה דקה. כך לא תנצלו את מלוא המכסה בשניות או שתיים הראשונות בכל דקה, והוא מגן עליכם מפני הפרעות בשירות במקרה של עלייה פתאומית בשימוש. כדי להתמודד עם ההבדלים באכיפה, עליכם לתכנן את השימוש במכסות ואת הדרישות, על ידי חישוב ממוצע של השימוש ב-QPM ב-QPS.
ממשקי ה-API של GMP שכוללים את אפשרות האכיפה לשנייה הם Directions API, לצבור Path Matrix API, Elevation API, Geocoding API, Places API ו- Roads API.