אנטי-דפוס: הפעלת קריאות ל-API לניהול משרת proxy של API

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

ל-Edge יש כלי רב-עוצמה שנקרא 'Manage APIs' (ממשקי API לניהול), שמציע שירותים כמו:

  • פריסה או ביטול פריסה של שרתי proxy ל-API
  • הגדרת מארחים וירטואליים, מאגרי מפתחות, מאגרי אמון וכו'.
  • יצירה, מחיקה ו/או עדכון של ישויות כמו KeyValueMaps,‏ מוצרי API, אפליקציות למפתחים, מפתחים, מפתחות של צרכנים וכו'.
  • מתבצע אחזור של מידע על הישויות האלה

ניתן לגשת לשירותים האלה דרך רכיב שנקרא שרת ניהול פלטפורמת Apigee Edge. אפשר להפעיל את השירותים האלה בקלות בעזרת ממשק API פשוט לניהול שיחות.

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

לדוגמה, אפשר לאחסן את המידע הבא ב-KeyValueMap כדי לשפר את האבטחה והגישה אליו במהלך זמן הריצה:

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

באופן דומה, ייתכן שתרצו לקבל את הרשימה של מוצרי ה-API או את כתובת האימייל של המפתח בזמן הריצה. המידע הזה יהיה זמין כחלק מפרופיל האפליקציות למפתחים.

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

דפוס שלילי

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

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

בדוגמת הקוד שבהמשך, הקריאה ל-API לניהול מתבצעת באמצעות קוד JavaScript המותאם אישית כדי מאחזרים את המידע מ-KeyValueMap:

var response = httpClient.send('https://api.enterprise.apigee.com/v1/o/org_name/e/env_name/keyvaluemaps/kvm_name')

אם שרת הניהול לא זמין, אז קוד ה-JavaScript שמפעיל את ממשק ה-API לניהול. הקריאה נכשלה. כתוצאה מכך, בקשת ה-API תיכשל.

השפעה

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

שיטה מומלצת

יש דרכים יעילות יותר לאחזור מידע מישויות כמו KeyValueMaps, API מוצרים, DeveloperApps, מפתחים, מפתחות צרכן וכו' בזמן הריצה. הנה כמה דוגמאות:

  • צריך להשתמש במדיניות KeyValueMapOperations כדי לגשת למידע מ-KeyValueMaps. הנה קוד לדוגמה שמראה איך לאחזר מידע מ-KeyValueMap: 
    <!-- /antipatterns/examples/2-6.xml -->
<KeyValueMapOperations mapIdentifier="urlMap" async="false"
    continueOnError="false" enabled="true" name="GetURLKVM">
  <DisplayName>GetURLKVM</DisplayName>
  <ExpiryTimeInSecs>86400</ExpiryTimeInSecs>
  <Scope>environment</Scope>
  <Get assignTo="urlHosti" index="2">
    <Key>
      <Parameter>urlHost_1</Parameter>
    </Key>
  </Get>
</KeyValueMapOperations>
  • כדי לגשת למידע על מוצרי API, אפליקציות למפתחים, מפתחים, מפתחות צרכן וכו'. ב-proxy ל-API אפשר לבצע אחת מהפעולות הבאות:
    • אם בתהליך ה-proxy של ה-API יש מדיניות VerifyAPIKey, תוכלו לגשת למידע באמצעות משתני הזרימה שמאוכלסים כחלק מהמדיניות הזו. קוד לדוגמה שמראה איך לאחזר את השם ואת המידע created_by של אפליקציה למפתחים באמצעות JavaScript: 
      <!-- /antipatterns/examples/2-7.xml -->
print("Application Name ", context.getVariable(""verifyapikey. VerifyAPIKey.app.name"));
print("Created by:", context.getVariable("verifyapikey. VerifyAPIKey.app.created_by"));
    • אם בתהליך ה-proxy של ה-API אין מדיניות VerifyAPIKey, יש לך אפשרות לגשת אל פרופילים של מוצרי API, אפליקציות למפתחים וכו', באמצעות משתני גישה ומשתני חילוץ למדיניות:
      1. אחזור הפרופיל של DeveloperApp באמצעות מדיניות AccessEntity: 
        <!-- /antipatterns/examples/2-8.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AccessEntity async="false" continueOnError="false" enabled="true" name="GetDeveloperApp">
  <DisplayName>GetDeveloperApp</DisplayName>
  <EntityType value="app"></EntityType>
  <EntityIdentifier ref="developer.app.name" type="appname"/>
  <SecondaryIdentifier ref="developer.id" type="developerid"/>
</AccessEntity>
      2. מחלצים את appId מ-DeveloperApp באמצעות המדיניות המחולקת למשתנים: 
        <!-- /antipatterns/examples/2-9.xml -->
<ExtractVariables name="Extract-Developer App-Info">
  <!--
    The source element points to the variable populated by AccessEntity policy.
    The format is <policy-type>.<policy-name>
    In this case, the variable contains the whole developer profile.
  -->
  <Source>AccessEntity.GetDeveloperApp"</Source>
  <VariablePrefix>developerapp</VariablePrefix>
  <XMLPayload>
    <Variable name="appld" type="string">
      <!-- You parse elements from the developer profile using XPath. -->
      <XPath>/App/AppId</XPath>
    </Variable>
  </XMLPayload>
</ExtractVariables>

קריאה נוספת