שירותי האינטרנט של הפלטפורמה של מפות Google הם אוסף של ממשקי HTTP של Google שירותים שמספקים נתונים גיאוגרפיים לאפליקציות המפות שלך.
במדריך הזה מתוארות כמה שיטות נפוצות שמועילות להגדרה של שירות אינטרנט ועיבוד תגובות לבקשות שירות. כדאי לעיין במדריך למפתחים לעיון בתיעוד המלא של Map Tiles API.
מהו שירות אינטרנט?
שירותי האינטרנט של הפלטפורמה של מפות Google הם ממשק לבקשת נתונים של Maps API מ- שירותים חיצוניים ושימוש בנתונים שבאפליקציות שלך במפות Google. השירותים האלה לשימוש בשילוב עם מפה, הגבלות על רישיונות בתנאים ובהגבלות של הפלטפורמה של מפות Google.
שירותי האינטרנט של ממשקי ה-API של מפות Google משתמשים בבקשות HTTP(S) לכתובות URL ספציפיות, ומעבירים פרמטרים של כתובות אתרים ו/או נתוני POST בפורמט JSON כארגומנטים לשירותים. בדרך כלל, שירותים אלה מחזירים נתונים גוף התגובה כ-JSON לצורך ניתוח ו/או בעיבוד באמצעות הבקשה שלך.
דוגמה לבקשת שירות אינטרנט היא בקשת מטא-נתונים של Street View, בצורה הבאה:https://tile.googleapis.com/v1/streetview/metadata?session=YOUR_SESSION_TOKEN &key=YOUR_API_KEY &panoId=panoId
הערה: כל האפליקציות בממשק ה-API של אריחי המפה מחייבות אימות. מידע נוסף על פרטי כניסה לאימות
גישת SSL/TLS
נדרש HTTPS בכל הבקשות של הפלטפורמה של מפות Google שמשתמשות במפתחות API או שמכילות משתמשים . בקשות שמבוצעות באמצעות HTTP ומכילות מידע אישי רגיש עשויות להידחות.
שימוש מנומס בממשקי API של Google
לקוחות API שמעוצבים באופן לא תקין יכולים לטעון יותר מהנדרש גם באינטרנט וגם השרתים של Google. הקטע הזה כולל כמה שיטות מומלצות ללקוחות של ממשקי ה-API. כבר במעקב השיטות המומלצות הבאות יכולות לעזור לכם למנוע את חסימת האפליקציה שלכם עקב ניצול לרעה של ממשקי ה-API.
השהיה מעריכית לפני ניסיון חוזר (exponential backoff)
במקרים נדירים, משהו יכול להשתבש בעת מילוי הבקשה שלכם; ייתכן שתקבלו קוד HTTP 4XX או 5XX קוד התגובה, או שחיבור ה-TCP עלול פשוט להיכשל במקום כלשהו בין הלקוח השרת. לעיתים קרובות יש טעם לנסות שוב את הבקשה בקשת ההמשך עשויה להצליח אם המקור נכשל. עם זאת, חשוב לא רק לבצע שוב ושוב בקשות לשרתים של Google. הלולאה הזו עלולה לגרום לעומס יתר בין הלקוח שלכם ל-Google, שגורמת לבעיות לגורמים רבים.
עדיף לנסות שוב ושוב עם יותר עיכובים בין הניסיונות. בדרך כלל ההשהיה מוגדלת בגורם מכפיל בכל ניסיון, גישה שנקראת השהיה מעריכית לפני ניסיון חוזר (exponential backoff).
לדוגמה, כדאי לבחון בקשה שרוצה להגיש את הבקשה הזו ממשק ה-API של אזור הזמן:
https://maps.googleapis.com/maps/api/timezone/json?location=39.6034810,-119.6822510×tamp=1331161200&key=YOUR_API_KEY
הדוגמה הבאה ב-Python מראה איך לשלוח את הבקשה עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff):
import json import time import urllib.error import urllib.parse import urllib.request # The maps_key defined below isn't a valid Google Maps API key. # You need to get your own API key. # See https://developers.google.com/maps/documentation/timezone/get-api-key API_KEY = "YOUR_KEY_HERE" TIMEZONE_BASE_URL = "https://maps.googleapis.com/maps/api/timezone/json" def timezone(lat, lng, timestamp): # Join the parts of the URL together into one string. params = urllib.parse.urlencode( {"location": f"{lat},{lng}", "timestamp": timestamp, "key": API_KEY,} ) url = f"{TIMEZONE_BASE_URL}?{params}" current_delay = 0.1 # Set the initial retry delay to 100ms. max_delay = 5 # Set the maximum retry delay to 5 seconds. while True: try: # Get the API response. response = urllib.request.urlopen(url) except urllib.error.URLError: pass # Fall through to the retry loop. else: # If we didn't get an IOError then parse the result. result = json.load(response) if result["status"] == "OK": return result["timeZoneId"] elif result["status"] != "UNKNOWN_ERROR": # Many API errors cannot be fixed by a retry, e.g. INVALID_REQUEST or # ZERO_RESULTS. There is no point retrying these requests. raise Exception(result["error_message"]) if current_delay > max_delay: raise Exception("Too many retry attempts.") print("Waiting", current_delay, "seconds before retrying.") time.sleep(current_delay) current_delay *= 2 # Increase the delay each time we retry. if __name__ == "__main__": tz = timezone(39.6034810, -119.6822510, 1331161200) print(f"Timezone: {tz}")
עליך גם להיזהר שאין ניסיון חוזר לקוד גבוה יותר בקריאה לאפליקציה שמובילה לבקשות חוזרות ברצף מהיר.
בקשות מסונכרנות
מספר גדול של בקשות מסונכרנות לממשקי ה-API של Google עשויות להיראות כמו בקשה מבוזרת התקפת מניעת שירות (DDoS) בתשתית של Google, וחשוב להתייחס אליה בהתאם. שפת תרגום להימנע מכך, עליכם לוודא שבקשות ה-API לא מסונכרנות בין הלקוחות.
לדוגמה, נבחן אפליקציה שמציגה את השעה באזור הזמן הנוכחי. סביר להניח שהאפליקציה הזו תגדיר התראה במערכת ההפעלה של הלקוח, שמוציאה אותה ממצב שינה תחילת הדקה כדי שיהיה אפשר לעדכן את השעה שמוצגת. האפליקציה צריכה לא תבצע קריאות ל-API כחלק מהעיבוד המשויך להתראה הזו.
ביצוע קריאות ל-API בתגובה להתראה קבועה אינו תקין כי הוא גורם לקריאות ל-API להיות מסונכרן עם תחילת הדקות, גם בין מכשירים שונים, במקום שמחולק באופן שווה לאורך הזמן. יישום שתוכנן בצורה גרועה יכול להביא לעלייה תנועה גדולה פי 60 מהרמות הרגילות בתחילת כל דקה.
במקום זאת, אפשרות טובה אחת היא להגדיר התראה שנייה למועד שנבחר באופן אקראי. כשההתראה השנייה מופעלת, האפליקציה קוראת לכל ממשקי ה-API שהיא צריכה ומאחסנת את תוצאות. כשהאפליקציה מבקשת לעדכן את התצוגה שלה בתחילת הדקות, היא משתמשת את התוצאות שנשמרו בעבר, במקום לקרוא שוב ל-API. בגישה הזאת, קריאות ל-API והן מחולקות באופן שווה לאורך זמן. כמו כן, הקריאות ל-API לא מעכבות את הרינדור כשהתצוגה בתהליך עדכון.
מלבד תחילת הדקה, זמנים נפוצים אחרים של סנכרון צריכים להיות זהירים לא לטירגוט: בתחילת שעה, ובתחילת כל יום בחצות.
מתבצע עיבוד של התשובות
בקטע הזה מוסבר איך לחלץ את הערכים האלה באופן דינמי מתשובות של שירותי אינטרנט.
שירותי האינטרנט של מפות Google מספקים תשובות קלות להבין, אבל לא בדיוק ידידותי למשתמש. כשמבצעים שאילתה, מאשר להציג את קבוצת הנתונים, אולי תרצו לחלץ כמה ערכים. באופן כללי, רצוי לנתח תשובות מהאינטרנט ומחלצים רק את הערכים שמעניינים אתכם.
סכימת הניתוח שבה משתמשים תלויה באפשרות שבה אתם חוזרים ב-JSON. תגובות JSON, שהן כבר בצורת אובייקטים של JavaScript, ניתן לעבד אותם בתוך JavaScript עצמו אצל הלקוח.