Skip to main content

בחירת דרך ההתאוששות המתאימה

אותו קוד שגיאה מתאר שני מצבים שונים. יש לבדוק את retryable לפני שנוקטים פעולה; סטטוס HTTP בלבד אינו מורה אם יש לנסות שוב.

קלט שונה

הבקשה עדיין בעיבוד

בדוגמה זו קיימת גם כותרת התגובה של HTTP‏ Retry-After: 1.

שמירה על זהות ניסיון חוזר יציבה

עבור פעולות שבהן מתועדת תמיכה באידמפוטנטיות, המפתח מוגבל להיקף של הארגון, חשבון השירות, שיטת ה-HTTP, נתיב המשאב וגרסת ה-API שנקבעה. שינוי של כל אחד מהם יוצר זהות ניסיון חוזר שונה; הוא אינו משחזר את הפעולה המקורית. החלפת אישור גישה (credential) תחת אותו חשבון שירות אינה משנה את הזהות הזו, אף שלאישור הגישה החלופי עדיין נדרשת הרשאה. יש לשמור על המפתח, גוף הבקשה, הנתיב והגרסה המקוריים בעת התאוששות מפקיעת זמן (timeout). אין ליצור מפתח חדש רק כדי לעקוף קונפליקט: ייתכן שפעולת הכתיבה המקורית כבר הצליחה. יש לאחזר את המשאב כאשר המזהה שלו ידוע, ולהשתמש בהליך ההתאוששות המתועד של הפעולה. תגובה חוזרת שהושלמה כוללת Idempotent-Replayed: true במקום שבו הפעולה מתעדת שחזור תגובה. שליחת Idempotency-Key אינה הופכת פעולה לאידמפוטנטית, אלא אם התיעוד שלה תומך בכותרת זו במפורש. ההגנה מפני ניסיונות חוזרים מוגבלת על ידי מדיניות השמירה של הפעולה; היא אינה מהווה ערובה קבועה מפני כפילויות. אם העיבוד נותר ללא פתרון, יש לפנות אל Living Security Support ולציין את request_id, חותמת זמן ב-UTC, שיטה, נתיב וגרסת API. אין לכלול לעולם מפתח API, סוד לקוח (client secret) או אסימון גישה (access token).