שיתוף פרטי הכניסה בין בקשות ה-API משפר את הביצועים ומפחית את התקורה המוגזמת שעלולה לגרום לשגיאות במגבלות קצב של יצירת בקשות. במדריך הזה מוסבר איך לבצע אופטימיזציה של הניהול של פרטי הכניסה ב-OAuth2 כדי שהאפליקציה שלכם תוכל לקיים אינטראקציה עם Google Ads API ביעילות.
האסטרטגיה שלכם לשיתוף של פרטי הכניסה תלויה בסוג האפליקציה: ריבוי שרשורים או ריבוי תהליכים (או תהליכים מבוזרים). אפליקציה שיש בה גם תהליכים מרובים וגם שרשורים מרובים בכל תהליך צריכה להשתמש בשתי האסטרטגיות. ניתן להתאים את האסטרטגיות האלה גם לחשבונות Google Ads מרובים.
ריבוי שרשורים
כל סשן או משתמש שנובע משרשור צריכים להשתמש באותו אובייקט של פרטי כניסה. צריך לבצע גם מרעננים של אסימוני גישה באופן סינכרוני כדי למנוע מרוץ תהליכים.
ספריות הלקוח שלנו מוודאות שפרטי הכניסה הם אובייקט בטוח לשרשורים, שמרעננים את עצמו באופן סינכרוני כשפג התוקף של אסימון הגישה. לכל אחת מספריות הלקוח יש אובייקט של סשן (או משתמש) עם פרטי כניסה שנעשה בו שימוש חוזר בכל משך החיים שלו. כדי לשתף את פרטי הכניסה בין השרשורים, צריך ליצור כל סשן באמצעות אותם פרטי כניסה. לדוגמה, בספריית הלקוח של Java, יוצרים סינגלטון Credential ומשתפים אותו בכל הסשנים.
ריבוי עיבוד או הפצה
בתהליכים מרובים או בתהליכים מבוזרים, צריך לשמור את פרטי הכניסה כדי שאפשר יהיה לשתף אותם. כדי להבטיח שכמה תהליכים או שרתים לא ינסו לרענן את פרטי הכניסה בו-זמנית, וכתוצאה מכך יהיו בקשות רענון מוגזמות, כדאי להקצות את הרענון לתהליך אחד.
לדוגמה, יכול להיות שמשימה או שירות נפרדים יגרמו לרענון מדי פעם של פרטי הכניסה ולהעברה שלהם באופן יזום למאגר נתונים שמשותף למאגר שרתים. כל שרת יכול לאחזר את פרטי הכניסה ממאגר הנתונים במהלך שליחת בקשת API.
רענון המשימה
פעולת הרענון צריכה לא להמתין עד שהתוקף של פרטי הכניסה הנוכחיים יפוג לפני התחלת הרענון. אם תעשו זאת, האפליקציה תעכב את הגישה בגלל היעדר פרטי כניסה תקפים. עם זאת, אם התוקף של אסימון הגישה של פרטי הכניסה יפוג במהלך העיבוד של בקשת ה-API, הבקשה עדיין תושלם והתוצאות יוחזרו.
מומלץ לעקוב אחרי המועד שבו בוצע הרענון האחרון של אסימון הגישה, ולאלץ רענון אם הוא נמשך פחות מ-5 דקות עד שהתוקף שלו פג.
אם לא יודעים מתי בוצע הרענון האחרון של אסימון הגישה, אפשר לנסות לרענן אותו בהנחה שהתוקף שלו כבר פג. אם אסימון הגישה לא קרוב לקפוץ, השרת מחזיר את אותו אסימון גישה, יחד עם אלפיות השנייה שנשארו עד שיפוג התוקף של האסימון.
מאגר הנתונים
אפשר להשתמש במאגר נתונים קיים או לפרוס מאגר נתונים ספציפי לשיתוף פרטי הכניסה בין שרתים. הפתרונות כוללים שרתי נתונים לשמירה במטמון, כמו Memcached או Infinispan, או מאגרי נתונים ב-NoSQL, כמו MongoDB.
צריך לבצע אופטימיזציה של מאגר הנתונים לפעולות קריאה מהירה, כי יהיו הרבה יותר בקשות קריאה מאשר בקשות כתיבה. בנוסף, פרטי הכניסה צריכים להיות מאוחסנים באופן מאובטח.
כשמאחסנים את פרטי הכניסה, צריך לאחסן את expiry_time
(עכשיו + expires_in) ו-refresh_token לצד access_token. הערך expiry_time מחושב כזמן של בקשת הרענון access_token בתוספת הזמן expires_in.
מאגר שרתים
כל שרת או תהליך במאגר מאחזרים את פרטי הכניסה האחרונים ממאגר הנתונים לפני שליחת הבקשה. כל עוד משימת הרענון פועלת באופן תקין, פרטי הכניסה תקפים. אבל אם משימת הרענון או מאגר הנתונים נכשלים, צריך להיות לכם מנגנון חלופי.
אם שרת או תהליך לא יכולים לקבל פרטי כניסה ממאגר הנתונים, או אם התוקף של פרטי הכניסה פג, השרת צריך לרענן את פרטי הכניסה שלו כדי לאפשר לאפליקציה להמשיך לעבוד עם ה-API עד שהבעיה תיפתר.
ניהול פרטי כניסה למספר חשבונות
פרטי כניסה שנוצרו לחשבון ניהול ב-Google Ads יכולים לשמש כדי לגשת לכל חשבונות הצאצא של חשבון הניהול. לכן, למשתמשים עם היררכיה אחת של חשבונות ניהול, בדרך כלל מספיק ליצור פרטי כניסה לחשבון הניהול ברמה העליונה, שישמשו לכל חשבונות Google Ads שנמצאים מתחתיו בהיררכיה.
אם האפליקציה שלכם צריכה לגשת לחשבונות Google Ads שלא קשורים זה לזה באף היררכיה של חשבון ניהול, צריך ליצור ולתחזק פרטי כניסה שונים לחשבונות שונים, למשל, לכל חשבון לקוח ב-Google Ads שאליו אתם ניגשים, או לכל חשבון ניהול ברמה עליונה בהיררכיות העצמאיות שאליהן ניגשים.
אפשר להשתמש באותן אסטרטגיות באפליקציות עם ריבוי שרשורים או באפליקציות ריבוי תהליכים / מבוזרות עם שינויים קלים. כשמשתמשים במאגר נתונים משותף, צריך להוסיף את פרטי הכניסה לאינדקס לפי מזהה החשבון customerId כדי לוודא שפרטי הכניסה משויכים לחשבון הנכון.
בנוסף, במשימת הרענון צריך לרענן את כל פרטי הכניסה. אם חשבון חדש מקושר, יכול להיות שיהיה צורך להפעיל את משימת הרענון.
לסיום, באפליקציות עם שרשורים מרובים, צריך לשתף את האובייקט של פרטי הכניסה רק בשרשורים שפועלים בחשבון שאליו משויך האובייקט של פרטי הכניסה.