יש תרחישים רבים שבהם יכולות להתרחש שגיאות בעבודה עם Display & Video 360 API. הן יכולות להיות קשורות לבאג בקוד, להזנה לא חוקית של משתמש או אפילו לבעיה ב-API עצמו. לא משנה מה הסיבה, חשוב לדעת איך לפתור בעיות שקשורות לשגיאות, כי זהו חלק חשוב בתהליך הפיתוח. במדריך הזה נספק כמה טיפים ושיטות מומלצות שיעזרו לכם להתחיל.
סקירה כללית על היסודות
- מומלץ לעיין במדריך הדרישות המוקדמות. מוודאים שיש לכם גישה ל-Display & Video 360 ולפרויקט API שהוגדר כראוי.
- אם התגובה מכילה שגיאות HTTP, חשוב לבדוק אותן היטב ולוודא שהבקשה נשלחת ל-API ולשירות הנכונים.
- המדריך להרשאה מוודאים שהבקשה מכילה את פרטי הכניסה הנדרשים ל-OAuth 2.0.
מוודאים שמשתמשים בפרטי הכניסה הנכונים. פרטים על יצירת פרטי כניסה לאימות מופיעים במדריך להגדרת האפליקציה. אפשר גם להעביר את אסימון הגישה לנקודת הקצה של tokeninfo ב-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, כתובות אימייל וכו'.
- קטע קוד. אם אתם מצליחים לבודד את הבעיה לקטע קוד מסוים או אם אתם חושדים שהבעיה ספציפית לשפה, כדאי לכלול קטע קוד קטן כדי להמחיש את מה שאתם עושים.
- מידע נוסף, כמו גרסת סביבת זמן הריצה/המתורגם והפלטפורמה, שיכול להיות שימושי לאנשים אחרים שמנסים לשחזר את הבעיה.
פתרון הבעיה
אחרי שתזהו את הגורם לבעיה ותמצאו פתרון, תוכלו להטמיע את התיקון. כשהדבר אפשרי, כדאי לבדוק את התיקון בסביבה מבוקרת (למשל, שותף או מפרסם שהוגדרו במיוחד לצורך בדיקה) עם מגוון של קלט תקין וקלוק, לפני הפריסה בסביבת הייצור.