אתם קוראים את מאמרי העזרה של Apigee Edge.
כדאי לעיין במסמכי העזרה בנושא Apigee X. מידע
מדיניות המכסות משמשת לספירת מספר הבקשות שמתקבלות על ידי שרת proxy של API. היכולת הזו מאפשרת לספקי API לאכוף מגבלות על מספר הקריאות ל-API שמבוצעות על ידי אפליקציות במרווח זמן מסוים.
מדיניות המכסות יכולה לכלול רכיב
identifier שמזהה את 'קטגוריית' המכסה שבה נספרת כל בקשה.
תבנית אנטי
כשמשתמשים במדיניות בנושא מכסות, לא מומלץ להשתמש במזהים בעלי עוצמה גבוהה.
העוצמה (cardinality) מתייחסת למספר הערכים הייחודיים במערך נתונים. מזהה עם עוצמה גבוהה הוא מזהה שיש לו מספר גדול של ערכים אפשריים שונים. מזהים בעלי עוצמה (cardinality) גבוהה כוללים מזהי בקשות ייחודיים או מזהי סשנים שמשתנים בכל קריאה ל-API.
שימוש במזהים בעלי עוצמה גבוהה יכול לפגוע משמעותית ביעילות של אכיפת המכסה.
השפעה
שימוש במזהים עם קרדינליות גבוהה ברכיב המזהה של מדיניות הקצאה גורם ל:
- אכיפת מכסת שימוש לא יעילה: כל מזהה ייחודי נחשב כמונה נפרד. אם לכל בקשה יש מזהה חדש וייחודי, מערכת הקצאה שלכם יוצרת למעשה 'מאגר' חדש לכל קריאה ל-API. המשמעות היא שמגבלת המכסה הכוללת נמדדת לפי מוניטורים נפרדים לשימוש חד-פעמי, ולא לפי קבוצות בפועל של בקשות שרוצים להגביל, ולכן המדיניות לא שימושית לבקרת תנועה.
- צריכת משאבים מוגברת: יצירה וניהול של מספר עצום של מוני מכסות ייחודיים יוצרים עומס מיותר על פלטפורמת Apigee, מה שמוביל לשימוש מוגבר במשאבים ולבעיות פוטנציאליות בביצועים.
- בעיות במעקב: קשה לעקוב אחרי מגמות הצריכה בפועל של ה-API ולהבין אותן כשהנתונים מפוצלים בין מספרים גדולים של מזהים ייחודיים. לא תהיה לכם יותר אפשרות לראות אילו אפליקציות, מפתחים או מוצרים צורכים את משאבי ה-API שלכם.
שיטה מומלצת
כדאי לבחור מזהים עם קרדינליות נמוכה עד בינונית, שמייצגים גם קיבוץ יציב ומשמעותי לאכיפת מכסת השימוש. הם עוזרים לכם לנהל את השימוש ב-API בצורה יעילה ולקבל תובנות לגבי התנועה. דוגמאות:
- developer.app.name
- client_id
- apiproduct.name
בעזרת מזהים מתאימים, מדיניות הקצאה יכולה לנהל את תנועת הנתונים ב-API בצורה יעילה יותר, למנוע חריגות לא מכוונות ולספק תובנות ברורות לגבי דפוסי השימוש.