הסבר על מסלולים

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X. מידע

נתיב קובע את הנתיב של בקשה מ-ProxyEndpoint ל-TargetEndpoint. בנתיב נכללות כתובת ה-URL שמשמשת לגישה ל-API ProxyEndpoint וכתובת ה-URL של שירות הקצה העורפי שמוגדר על ידי TargetEndpoint.

בסרטון הבא מוצג מבוא למסלולים, שמתאר את הקשר בין ProxyEndpoint ל-TargetEndpoint.

קביעת כתובת ה-URL של נקודת הקצה של שרת proxy ל-API

בתמונה הבאה מוצגת בקשה שנכנסת ל-ProxyEndpoint מאפליקציה מסוימת, והבקשה מפנה לשירות הקצה העורפי:

אחרי שיוצרים שרת proxy ל-API ב-Edge, כתובת ה-URL שמשמשת כברירת מחדל באפליקציה לצורך גישה לשרת ה-proxy היא:

http://{org-name}-{env-name}.apigee.net/{base-path}/{resource-path}

https://{org-name}-{env-name}.apigee.net/{base-path}/{resource-path}

איפה:

  • {org-name} הוא שם הארגון שלך. השם הזה נוצר כשיוצרים חשבון ב-Edge.
  • {env-name} הוא השם של סביבת Edge. כברירת מחדל, לכל הארגונים ב-Apigee שנוצרים בענן יש שתי סביבות: 'test' ו-'prod'. במהלך הפריסה של שרת proxy ל-API, אפשר לבחור לפרוס אותו באחת מהסביבות או בשתיהן.
  • {base-path} ו-{resource-path} מוגדרים כשיוצרים את שרת ה-API של שרת ה-API.

כשבקשה מגיעה ל-Edge, מנתח Edge את כתובת ה-URL כדי להפנות את הבקשה ל-ProxyEndpoint הנכון. לדוגמה, כדי לגשת לשרת proxy של API ב-Edge, כתובת ה-URL הבאה:

http://myOrg-prod.apigee.net/v1/weather/forecastrss

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

  1. קטע הדומיין בכתובת ה-URL, http://myOrg-prod.apigee.net, תואם למארח וירטואלי ב-Edge. בהגדרה ProxyEndpoint שלמעלה, שרת ה-API של שרת ה-proxy משתמש בתג <VirtualHost> כדי להפנות למארח וירטואלי בשם default. אפשר להגדיר כמה מארחים וירטואליים בסביבה.

    מארח וירטואלי מגדיר את הדומיינים והיציאות שבהם שרת proxy של API חשוף. מארח וירטואלי גם מגדיר אם הגישה לשרת ה-proxy של ה-API מתבצעת באמצעות פרוטוקול HTTP, או באמצעות פרוטוקול HTTPS מוצפן. מידע מפורט על מארחים וירטואליים זמין במאמר מידע על מארחים וירטואליים (בטא).
  2. החלק השני של כתובת ה-URL, /v1/weather, נקבע על ידי הרכיב <BasePath> ב-ProxyEndpoint. הנתיב הבסיסי חייב להיות ייחודי לשרת ה-proxy של ה-API של הסביבה, כך שלשני שרתי proxy של API לא יהיה אותו נתיב בסיס.
  3. החלק השלישי של כתובת ה-URL, /forecastrss, הוא משאב שמוגדר על ידי שרת ה-proxy של ה-API, עם התהליך המותנה התואם שמוגדר על ידי התג <Flows>.

סרטון: מומלץ לצפות בסרטון קצר כדי לקבל מידע נוסף על נקודות קצה לשרת proxy של API.

קביעת כתובת ה-URL של נקודת הקצה של היעד

התג <RouteRule> בהגדרה של ProxyEndpoint קובע את היעד של שרת ה-proxy של ה-API, ומתבצעת הערכה שלו אחרי העיבוד של כל כללי המדיניות בשדות PreFlow, Conditionalflow ו-PostFlow של בקשת ProxyEndpoint.

נקודת ProxyEndpoint יכולה להגדיר את היעד כך:

  • כתובת URL ישירה לשירות לקצה העורפי.
  • הגדרה אחת של TargetEndpoint.
  • מספר נקודות יעד (TargetEndpoints), שבהן שרת ה-proxy של ה-API מאציל את הבקשה לנקודת קצה (endpoint) של יעד על סמך תנאי.
  • אין מסלול או יעד, כלומר הבקשה לא מועברת ליעד. במקום זאת, כל עיבוד הבקשה ויצירת התגובה מתבצעים ב-Edge.

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

כתובת URL ישירה

ProxyEndpoint יכול להפעיל באופן ישיר שירות לקצה העורפי, תוך עקיפה של כל הגדרת TargetEndpoint בשם. לדוגמה, המחרוזת <RouteRule> הבאה תמיד שולחת קריאה ל-HTTP אל http://api.mycompany.com/myAPI:

<RouteRule name="default">
  <URL>http://api.mycompany.com/myAPI</URL> 
</RouteRule>

עם זאת, מאחר שאין TargetEndpoint, אפשר רק להוסיף כללי מדיניות לתהליכי העבודה שהוגדרו על ידי ProxyEndpoint.

יעד יחיד

בהגדרת יעד אחת, ה-ProxyEndpoint מפנה להגדרת TargetEndpoint אחת לפי שם, כפי שמוצג באיור למעלה:

<RouteRule name="default">
  <TargetEndpoint>default</TargetEndpoint>
</RouteRule>

כל הבקשות לשרת ה-proxy הזה של ה-API מופנות לאותה הגדרת TargetEndpoint. התג <URL> ב-TargetEndpoint קובע את המיקום של השירות לקצה העורפי. באיור שלמעלה, כתובת ה-URL של היעד היא http://weather.yahooapis.com.

יעדים מותנים

התג <RouteRule> מאפשר להפנות בקשה ליעד לפי תנאי. אפשר להשתמש במשתני זרימה, בפרמטרים של שאילתות, בכותרות HTTP, בתוכן של הודעות או במידע לפי הקשר כמו שעה ביום ומיקום כדי לקבוע את נקודת הקצה (endpoint) של היעד. לדוגמה, אפשר לכלול אזור גיאוגרפי, כמו ארה"ב ובריטניה, בכתובת URL של בקשה. לאחר מכן אפשר לנתב בקשה לנקודת קצה (endpoint) של יעד על סמך האזור.

כלל הנתיב הבא מעריך כותרת HTTP בבקשה. אם כותרת ה-HTTP routeTo כוללת את הערך TargetEndpoint1, הבקשה מועברת ל-TargetEndpoint בשם TargetEndpoint1. אם לא, הבקשה תועבר אל TargetEndpoint2.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
 <TargetEndpoint>TargetEndpoint2</TargetEndpoint>
</RouteRule>

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

למידע נוסף, ניתן לעיין גם במסלולים מותנים ובמידע על תנאים.

סרטון: מומלץ לצפות בסרטון קצר עם הסברים על ניתוב לנקודת קצה (endpoint) של יעד באמצעות יעדים מותנים.

מסלול אפס

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

בדוגמה הבאה מוגדר נתיב null:

<RouteRule name="GoNowhere"/>

מידע נוסף