שיתוף פרטי הכניסה בין בקשות ה-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 כדי לוודא שפרטי הכניסה משויכים לחשבון הנכון.
בנוסף, משימת הרענון אמורה לרענן את כל פרטי הכניסה. אם חשבון חדש מקושר, יכול להיות שצריך להפעיל את משימת הרענון.
לבסוף, באפליקציות עם שרשורים מרובים, יש לשתף את אובייקט פרטי הכניסה רק בשרשורים שפועלים בחשבון שאליו משויך אובייקט פרטי הכניסה.