מהי מדיניות?

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

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

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

בסרטון הזה מוצג הסבר על צירוף קובץ המדיניות ואכיפת המדיניות.

סוגי מדיניות

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

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

ניהול טראפיק

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

אבטחה

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

גישור

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

Extension

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

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

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

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

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

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

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

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

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

המשמעות היא ששירותי API אוכפים את מדיניות המכסות.

טיפול בתקלות לפי המדיניות

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

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

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

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

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

תהליך הבקשה של נקודת קצה לשרת proxy:
  1. SpikeArrest
  2. XMLThreatProtection או JSONThreatProtection
  3. אימות של מפתח API
  4. מכסה
  5. ResponseCache
תהליך התגובה של ProxyEndpoint:
  1. ResponseCache

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

תהליך הבקשה:
  1. SpikeArrest
  2. JSONThreatProtection
  3. אימות של מפתח API
  4. מכסה
  5. JSONToXML
תהליך התשובות:
  1. קובץ XMLToJSON
  2. ResponseCache