אישור
כל הבקשות ל-Google Photos Library API חייבות לקבל הרשאה ממשתמש מאומת.
הפרטים של תהליך ההרשאה עבור OAuth 2.0 משתנים מעט בהתאם בהתאם לסוג האפליקציה שאתם כותבים. התהליך הכללי הבא חלה על כל סוגי האפליקציות:
- כדי להתכונן לתהליך ההרשאה:
- לרשום את האפליקציה באמצעות מסוף Google API.
- להפעיל את Library API ולאחזר פרטי OAuth כמו מזהה הלקוח וסוד לקוח. מידע נוסף זמין במאמר הבא: כדי להתחיל, אפשר ללחוץ כאן.
- כדי לגשת לנתוני המשתמש, האפליקציה שולחת ל-Google בקשה היקף גישה מסוים.
- Google מציגה מסך הסכמה למשתמש שמבקש ממנו לאשר את לבקש חלק מהנתונים שלהם.
- אם המשתמש יאשר את הבקשה, Google תספק לאפליקציה אסימון גישה שהתוקף שלהם פג אחרי פרק זמן קצר.
- האפליקציה שולחת בקשה לנתוני המשתמש ומצרפת את אסימון הגישה לבקשה.
- אם Google תקבע שהבקשה והאסימון תקפים, היא תחזיר את הנתונים המבוקשים.
כדי לקבוע אילו היקפי הרשאות מתאימים לאפליקציה שלכם, אפשר לעיין בהרשאה היקפים.
התהליך בסוגי אפליקציות מסוימים כולל שלבים נוספים, כמו שימוש אסימוני רענון כדי לקבל אסימוני גישה חדשים. לקבלת מידע מפורט על עבור סוגים שונים של אפליקציות, ראה שימוש ב-OAuth 2.0 כדי לגשת אל ממשקי API.
שמירה במטמון
שמירה על עדכניות הנתונים.
אם אתם צריכים לאחסן מדיה באופן זמני (כמו תמונות ממוזערות, תמונות או סרטונים) מטעמי ביצועים, אין לשמור אותו במטמון למשך יותר מ-60 דקות לכל שימוש הנחיות קפדניות.
בנוסף, לא כדאי לאחסן את baseUrls, שהתוקף שלו יפוג אחרי כ-60 ימים
דקות.
מזהים של פריטי מדיה ומזהי אלבומים שמזהים באופן ייחודי את התוכן בספריית המשתמש פטורים מהגבלת השמירה במטמון. אפשר לשמור את המזהים האלה ללא הגבלת זמן (בכפוף למדיניות הפרטיות של האפליקציה שלך). שימוש במזהי פריטי מדיה ובמזהי אלבומים כדי לאחזר שוב נתונים וכתובות URL נגישים באמצעות נקודות הקצה המתאימות. עבור מידע נוסף זמין במאמר הורדת מדיה iteming או Listing [פריט] אלבומים.
אם יש הרבה פריטי מדיה שצריך לרענן, יכול להיות שיהיה יעיל יותר לאחסן את פרמטרים של חיפוש שהחזירו את פריטי המדיה ושולחים מחדש את השאילתה כדי לטעון מחדש .
גישת SSL
נדרש HTTPS עבור כל הבקשות של שירותי האינטרנט של Library API באמצעות כתובת ה-URL הבאה:
https://photoslibrary.googleapis.com/v1/service/output?parameters
בקשות שמבוצעות באמצעות HTTP נדחות.
טיפול בשגיאות
למידע נוסף על אופן הטיפול בשגיאות שהוחזרו מה-API, ראו Cloud טיפול בממשקי API .
ניסיון חוזר של בקשות שנכשלו
הלקוחות צריכים לנסות שוב בשגיאות 5xx עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff), כפי שמתואר ב-
השהיה מעריכית לפני ניסיון חוזר (exponential backoff). משך הזמן המינימלי צריך להיות 1 s
אלא אם צוין אחרת.
עבור שגיאות 429, הלקוח יכול לנסות שוב עם עיכוב של 30s לפחות. לכל שאר המשתמשים
שגיאות, ייתכן שהניסיון החוזר לא רלוונטי. צריך לוודא שהבקשה אידמפוטנטית
הודעת השגיאה לקבלת הנחיות.
השהיה מעריכית לפני ניסיון חוזר (exponential backoff)
במקרים נדירים, משהו יכול להשתבש בשליחת הבקשה שלכם.ייתכן שתקבלו
קוד תגובת HTTP 4XX או 5XX, או שחיבור ה-TCP עלול להיכשל במקום כלשהו
בין הלקוח שלכם לשרת של Google. לעיתים קרובות כדאי לנסות שוב
בקשה. בקשת ההמשך עשויה להצליח אם הבקשה המקורית נכשלה. אבל, לפעמים
חשוב לא להפעיל בלופ, לשלוח בקשות שוב ושוב לשרתים של Google. הזה
לולאות יכולות לגרום לעומס יתר על הרשת בין הלקוח ל-Google
לגרום בעיות לגורמים רבים.
עדיף לנסות שוב ושוב עם יותר עיכובים בין הניסיונות. בדרך כלל, בכל ניסיון להגדיל את ההשהיה בגורם מכפיל, שנקרא 'מעריכי' השהיה לפני ניסיון חוזר (backoff).
עליך גם לוודא שאין ניסיון חוזר לקוד גבוה יותר באפליקציה שמובילה לבקשות חוזרות ברצף מהיר.
שימוש מנומס בממשקי API של Google
לקוחות API המעוצבים באופן לא תקין יכולים להציב עומס גדול יותר מהנדרש ובשרתים של Google. הקטע הזה מכיל כמה שיטות מומלצות של ממשקי ה-API. אם תפעלו לפי השיטות המומלצות הבאות, תוכלו להימנע נחסמה בגלל ניצול לרעה של ממשקי ה-API.
בקשות מסונכרנות
מספר גדול של בקשות מסונכרנות לממשקי ה-API של Google עשוי להיראות כמו התקפת מניעת שירות מבוזרת (DDoS) בתשתית של Google, ובנוסף להתייחס אליהם בהתאם. כדי להימנע מכך, צריך לוודא שבקשות ה-API לא מסונכרן בין לקוחות.
לדוגמה, נבחן אפליקציה שמציגה את השעה בשעה הנוכחית תחום. סביר להניח שהאפליקציה הזו תגדיר התראה במערכת ההפעלה של הלקוח להוציא אותו ממצב שינה בתחילת הדקה, כדי שהשעה המוצגת עודכן. האפליקציה לא צריכה לבצע קריאות ל-API כחלק מהעיבוד שקשור להתראה הזו.
ביצוע קריאות ל-API בתגובה להתראה מתוקנת היא בעייתית, כי היא מובילה קריאות ל-API שמסתנכרנות עם תחילת הדקות, גם בין של המכשירים, במקום לפזר אותם באופן שווה לאורך זמן. תמונה שתוכננה בצורה גרועה כך תייצר עלייה חדה בנפח התנועה פי 60 מהרמות הרגילות בתחילת כל דקה.
במקום זאת, אפשרות טובה אחת היא להגדיר התראה שנייה באופן אקראי בזמן שנבחר. כשההתראה השנייה מופעלת, האפליקציה מבצעת שיחות ממשקי ה-API שדרושים לו ושומרים את התוצאות. כדי לעדכן את התצוגה בתחילת דקה, האפליקציה משתמשת בתוצאות שאוחסנו קודם לכן במקום להתקשר API שוב. בגישה הזו, הקריאות ל-API מחולקות באופן שווה לאורך הזמן. בנוסף, הקריאות ל-API לא מעכבות את הרינדור כשהתצוגה מתעדכנת.
מלבד תחילת הדקות, זמני סנכרון נפוצים אחרים צריך להקפיד לא למקד בתחילת השעה ובתחילת בכל יום בחצות.