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

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

מסלול קובע את הנתיב של בקשה מ-ProxyEndpoint ל-TargetEndpoint. המסלול כולל את כתובת ה-URL שמשמשת לגישה ל-API ProxyEndpoint ואת כתובת ה-URL של שירות ה-Backend שמוגדר על ידי 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}

where:

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

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

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

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

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

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

סרטון: סרטון קצר עם מידע נוסף על נקודות קצה של proxy ל-API.

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

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

ב-ProxyEndpoint אפשר להגדיר את היעד כ:

  • כתובת URL ישירה לשירות קצה עורפי.
  • הגדרה אחת של TargetEndpoint.
  • ‫Multiple TargetEndpoints שבהם ה-API proxy מעביר את הבקשה לנקודת קצה של יעד על סמך תנאי.
  • נתיב או יעד מסוג Null, כלומר הבקשה לא מועברת ליעד. במקום זאת, כל העיבוד של הבקשה ויצירת התשובה מתבצעים ב-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 קובע את המיקום של שירות ה-Backend. באיור שלמעלה, כתובת ה-URL של היעד היא http://weather.yahooapis.com.

יעדים מותנים

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

כלל הניתוב הבא מעריך כותרת 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.

כדאי לעיין גם במאמרים בנושא ניתוב מותנה והפניה לתנאים.

סרטון: בסרטון קצר אפשר ללמוד איך להגדיר ניתוב לנקודת קצה של יעד באמצעות יעדים מותנים.

מסלול ריק

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

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

<RouteRule name="GoNowhere"/>

מידע נוסף