מהי מדיניות?

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

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

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

בנושא הזה מוסבר על סוגי המדיניות ועל השימוש בהם ב-Apigee. מידע על מדיניות ספציפית זמין בסקירה הכללית של מדיניות.

סוגים וקטגוריות של כללי מדיניות

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

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

AI

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

תוסף

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

תהליך בחירת הרשת (Mediation)

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

אבטחה

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

ניהול תנועה

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

צירוף כללי מדיניות

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

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

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

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

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

http://ORG_NAME-test.apigee.net/weather/forecastrss?w=12797282

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

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

ההודעה הזו מציינת שמדיניות Quota נאכפת על ידי Apigee.

טיפול בתקלות על סמך מדיניות

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

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

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

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

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

תהליך הבקשה של ProxyEndpoint:
  1. SpikeArrest
  2. XMLThreatProtection או JSONThreatProtection
  3. אימות של מפתח API
  4. Quota
  5. ResponseCache
תהליך התגובה של ProxyEndpoint:
  1. ResponseCache

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

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