אנטי-תבנית: הפעלת קריאות ל-Apigee API מ-proxy ל-API

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

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

ל-Apigee יש כלי עזר עוצמתי שנקרא Apigee API, שמציע שירותים כמו:

  • פריסה או ביטול פריסה של שרתי proxy של API
  • הגדרת מארחים וירטואליים, מאגרי מפתחות, מאגרי אישורים וכו'
  • יצירה, מחיקה ועדכון של ישויות כמו מיפויים של זוגות מפתח/ערך (KVM), מוצרי API, אפליקציות למפתחים, מפתחים, מפתחות צרכן וכו'
  • אחזור מידע על הישויות האלה

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

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

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

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

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

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

תבנית אנטי

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

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

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

var response = httpClient.send('https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/keyvaluemaps')

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

השפעה

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

שיטה מומלצת

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

  • כדי לגשת למידע מ-KVM, משתמשים במדיניות KeyValueMapOperations. זוהי דוגמת קוד שמראה איך לאחזר מידע מ-KVM: 
    <!-- /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, אפשר לבצע אחת מהפעולות הבאות:
    • אם יש לכם מדיניות VerifyAPIKey בזרימת API Proxy, תוכלו לגשת למידע באמצעות משתני הזרימה שאוכלסו כחלק מהמדיניות הזו. הנה קוד לדוגמה שמראה איך לאחזר את השם ואת המידע על 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"));
    • אם ל-API Proxy flow שלכם אין VerifyAPIKey policy, אתם יכולים לגשת לפרופילים של מוצרי API, אפליקציות למפתחים וכו' באמצעות מדיניות AccessEntity ו-ExtractVariables:
      1. שליפת הפרופיל של אפליקציית המפתח באמצעות מדיניות 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 מאפליקציית המפתח באמצעות מדיניות ExtractVariables: 
        <!-- /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>

קריאה נוספת