מהי מדיניות?

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

‫Apigee Edge מאפשר לכם 'לתכנת' את התנהגות ה-API בלי לכתוב קוד, באמצעות 'מדיניות'. מדיניות היא כמו מודול שמיישם פונקציית ניהול ספציפית ומוגבלת. המדיניות נועדה לאפשר לכם להוסיף בקלות ובאופן מהימן סוגים נפוצים של יכולות ניהול ל-API. המדיניות מספקת תכונות כמו אבטחה, הגבלת קצב, טרנספורמציה ויכולות גישור, כך שלא תצטרכו לכתוב קוד ולתחזק את הפונקציונליות הזו בעצמכם.

אתם לא מוגבלים לסוגי המדיניות שמופיעים ב-Apigee Edge. אפשר גם לכתוב סקריפטים וקוד בהתאמה אישית (כמו אפליקציות JavaScript ו-Node.js), שמרחיבים את הפונקציונליות של proxy ל-API ומאפשרים לכם לחדש על בסיס יכולות הניהול הבסיסיות שנתמכות על ידי Apigee Policies.

סוגי מדיניות

מבחינה טכנית, מדיניות היא קובץ הגדרות בפורמט XML. המבנה של כל סוג מדיניות (לדוגמה, רכיבי ההגדרה הנדרשים והאופציונליים) מוגדר על ידי סכימת XML. אם יש לכם ניסיון בכלי XML, כדאי לעיין בסכימות המדיניות בדוגמאות של API Platform ב-GitHub.

סוגי המדיניות ב-Edge מחולקים לקטגוריות הפונקציונליות הבאות:

ניהול טראפיק

מדיניות בקטגוריה 'ניהול תעבורת נתונים' מאפשרת לכם לשלוט בזרימה של הודעות בקשה ותגובה דרך proxy ל-API. המדיניות הזו תומכת בשליטה ברמה התפעולית וברמה העסקית. הן מאפשרות לכם לשלוט בנתוני התפוקה הגולמיים, ויכולות גם לשלוט בתנועה על בסיס כל אפליקציה. סוגי מדיניות לניהול תנועה מאפשרים לאכוף מכסות, ועוזרים גם לצמצם את הסיכון למתקפות מניעת שירות (DoS).

אבטחה

כללי המדיניות בקטגוריית האבטחה תומכים באימות, בהרשאה ובאבטחה שמבוססת על תוכן.

גישור

מדיניות בקטגוריה 'תהליך בחירת הרשת' מאפשרת לכם לשנות באופן פעיל את ההודעות בזמן שהן עוברות דרך שרתי proxy של API. הן מאפשרות להמיר פורמטים של הודעות, מ-XML ל-JSON (ולהפך), או להמיר פורמט XML אחד לפורמט XML אחר. הם גם מאפשרים לכם לנתח הודעות, ליצור הודעות חדשות ולשנות ערכים בהודעות יוצאות. מדיניות גישור פועלת גם עם שירותים בסיסיים שנחשפים על ידי API Services, ומאפשרת לאחזר נתונים על אפליקציות, מפתחים, אסימוני אבטחה ומוצרי API בזמן ריצה.

Extension

מדיניות בקטגוריית התוספים מאפשרת לכם לנצל את יכולת ההרחבה של שירותי API כדי להטמיע התנהגות מותאמת אישית בשפת התכנות שתבחרו.

כל סוג מדיניות מתועד בפירוט בסקירה הכללית של חומר העזר בנושא מדיניות. במאמר הזה נסביר על אינטראקציה כללית, ונראה לכם איך ליצור מדיניות ואיך לצרף אותה ל-Flows בהגדרת proxy ל-API.

פריסת שינויים במדיניות

כדי שהשינויים במדיניות ייכנסו לתוקף, צריך לפרוס את הגרסה של ה-API Proxy בסביבה. אחרי שמצרפים מדיניות או מבצעים שינויים במדיניות קיימת, צריך להשתמש בממשק המשתמש לניהול או ב-API לניהול כדי לפרוס את השינויים.

אימות של אכיפת המדיניות

כדי לוודא שמדיניות נאכפת בצורה תקינה, צריך להפעיל את ה-API באמצעות לקוח HTTP. כדי לאמת את הגדרת המכסה הזו, שולחים כמה בקשות ל-API, מעבר למגבלת המכסה שהגדרתם במדיניות המכסות. (נתיב ה-URI, שהוגדר כהגדרת נתיב הבסיס ב-ProxyEndpoint, בבקשה שלמטה הוא /weather).

http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

אם שולחים יותר מבקשה אחת בתוך דקה, אמורה להופיע הודעת השגיאה הבאה:

{  
   "fault":{  
      "faultstring":"policies.ratelimit.QuotaViolation",
      "detail":{  
         "errorcode":"policies.ratelimit.QuotaViolation"
      }
   }
}

המשמעות היא שמדיניות המכסות נאכפת על ידי API Services.

טיפול בשגיאות על סמך מדיניות

שימו לב לפורמט של הודעת השגיאה שלמעלה. הוא מכיל נכס faultstring ונכס errorcode. במקרים רבים, צריך להטמיע התנהגות מסוימת כדי לטפל בשגיאות האלה. לדוגמה, יכול להיות שתרצו לשלוח הודעה מותאמת אישית למפתח שהאפליקציה שלו חרגה מהמכסה.

מידע נוסף על טיפול בשגיאות זמין במאמר טיפול בשגיאות.

שיטות מומלצות: קבוצות מדיניות נפוצות

כדי לעמוד בדרישות בסיסיות של ניהול, פרוקסי של API בדרך כלל אוכף את כללי המדיניות הבאים:

אימות בסיסי של מפתח API

1. SpikeArrest
2. ‫XMLThreatProtection או JSONThreatProtection
3. אימות של מפתח API
4. מכסה
5. ResponseCache

1. ResponseCache

טרנספורמציה בסיסית: מ-JSON ל-XML

1. SpikeArrest
2. JSONThreatProtection
3. אימות של מפתח API
4. מכסה
5. JSONToXML

1. XMLToJSON
2. ResponseCache