יש תרחישים רבים שבהם אתם עלולים להיתקל בשגיאות במהלך עבודה עם Display & Video 360 API. הסיבות לכך יכולות להיות באג בקוד, קלט לא חוקי של משתמש או אפילו בעיה ב-API עצמו. לא משנה מה הסיבה, חשוב לדעת איך לתקן שגיאות בתהליך הפיתוח. המדריך הזה כולל כמה טיפים לשיטות מומלצות שיעזרו לכם להתחיל.
סקירת היסודות
- עיינו במדריך הדרישות המוקדמות. ודאו שיש לכם גישה ל-Display & Video 360 ולפרויקט ה-API שהוגדר כראוי.
- אם התשובה מכילה שגיאות HTTP, חשוב לבדוק אותן בקפידה ולוודא שהבקשה נשלחת ל-API ולשירות הנכונים.
- עיינו במדריך ההרשאות. ודאו שהבקשה כוללת את פרטי הכניסה הנחוצים של OAuth 2.0.
מוודאים שאתם משתמשים בפרטי הכניסה הנכונים. לפרטים על יצירת פרטי כניסה לאימות, קראו את המדריך להגדרת אפליקציות. תוכלו גם להעביר את אסימון הגישה אל נקודת הקצה של פרטי האסימון של Google OAuth2 API, כדי לוודא שהוא הונפק לפרויקט ה-API הנכון וקיבלתם הרשאה להיקפים הנכונים:
POST https://www.googleapis.com/oauth2/v2/tokeninfo?access_token={YOUR_ACCESS_TOKEN} 200 OK { "issued_to": "{API_PROJECT_CLIENT_ID}", "audience": "...", "scope": "{API_SCOPES}", "expires_in": ... }
הבנת השגיאות
כשה-API נתקל בשגיאה, הוא בדרך כלל מחזיר תגובת JSON שמכילה אובייקט error. האובייקט הזה מספק הקשר נוסף לגבי השגיאה הספציפית שזוהתה.
{
"error": {
"code": 404,
"message": "Resource type LINE_ITEM does not exist: advertisers/1/lineItems/1",
"status": "NOT_FOUND"
}
}
בדרך כלל, התוכן של האובייקט error יכיל מספיק מידע כדי לעזור לך לזהות מה השתבש. אם לא, ייתכן שתצטרכו לבצע מחקר נוסף כדי להבין מה המשמעות של השגיאה.
בדיקת שגיאות
עיינו בקטע על שגיאות נפוצות, שמספק פרטים על חלק מהשגיאות הנפוצות ביותר.
אם השגיאה לא מופיעה בקטע של השגיאות הנפוצות, תוכלו לעיין במסמכי העזר ולנסות לחפש את קוד השגיאה, הסטטוס וההודעה.
אם תיתקלו בשגיאות שלא תועדו, דווחו לנו על כך.
זיהוי שורש הבעיה
בשלב הזה כבר זיהיתם את השגיאה והבנתם מה המשמעות שלה. אם לא, קראו את המאמר הבנת השגיאות או דלגו קדימה לקבלת עזרה, אם אתם סבורים שנתקלתם בשגיאה ב-API שלא תוכלו לתקן בעצמכם.
לפני שתוכלו לתקן את השגיאה, עליכם לזהות מה גורם לה. לעיתים קרובות מדובר בבאג בקוד או בערך לא חוקי של קלט.
כדי לקבוע אם הבעיה קשורה לבאג בקוד, קודם כל צריך לוודא שהקוד פועל כראוי. בתור התחלה, כדאי לבדוק את הקטע בקוד שאחראי על שליחת הבקשה שנכשלה כדי לבדוק אם יש בעיות ברורות. במקרים מסוימים, יכול להיות שתצטרכו להשתמש בכלי לניפוי באגים כדי לבדוק את הקוד שורה אחר שורה כדי לוודא שהוא פועל בצורה תקינה.
בדיקת בקשות HTTP היא דרך שימושית נוספת לזהות באגים אפשריים, כמו גם מקרים של קלט לא חוקי. בהרבה מספריות הלקוח הרשמיות אפשר להגדיר רישום של בקשות ותגובות מסוג HTTP. לפרטים נוספים, כדאי לעיין בתיעוד של הספרייה שבחרתם. אפשר גם להשתמש בשרת proxy מסוג HTTP כמו Charles, Squid או Fiddler לתיעוד יומני בקשות ותגובות. אחרי שאתם מקבלים את היומנים האלה, אתם צריכים לבדוק אותם כדי לוודא שערכי הפרמטרים של הבקשות שאתם שולחים באפליקציה נכונים ותואמים לציפיות שלכם.
ברגע שתזהו את הבאג או הקלט הלא חוקי שגרמו לשגיאה, אני מקווה שהתיקון יהיה ברור. אם נתקעתם או לא בטוחים מה הדרך הכי טובה לפתור את הבעיה, תוכלו להיעזר במידע שאספתם עד עכשיו.
קבלת עזרה
אם אתם לא מצליחים לפתור את הבעיה בעצמכם, תוכלו לפנות לצוות התמיכה שלנו באמצעות הטופס הזה במרכז העזרה של Display & Video 360.
כשממלאים את הטופס, חשוב לכלול כמה שיותר פרטים על הבעיה שנתקלתם בה ועל שלבי פתרון הבעיות שכבר ביצעתם. מידע שימושי שכדאי לכלול:
- יומני הבקשות והתגובות של HTTP. הקפידו לצנזר מידע רגיש כמו אסימוני גישה מסוג OAuth 2.0, כתובות אימייל וכו'.
- קטע קוד. אם אתם מצליחים לבודד את הבעיה רק בקטע מסוים בקוד, או חושדים שהבעיה היא ספציפית לשפה, תוכלו להוסיף לה קטע קוד קצר שימחיש את הפעולה.
- מידע נוסף, כמו הפלטפורמה וגרסת זמן הריצה/המתורגמן, שיכול לעזור לאחרים שמנסים לשחזר את הבעיה.
פתרון הבעיה
לאחר שתזהו את הגורם לבעיה ותעלו פתרון, תוכלו ליישם את התיקון. כשזה אפשרי, כדאי לבדוק את התיקון בסביבה מבוקרת (למשל אצל שותף או מפרסם שהוגדרו ספציפית לבדיקות) מול מגוון קלטים טובים וגרועים, לפני הפריסה בסביבת ייצור.