כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של
Apigee X. מידע
שרת proxy ל-API הוא חזית מנוהלת לשירותים לקצה העורפי. הגדרה בסיסית של שרת proxy ל-API כוללת ProxyEndpoint (הגדרת כתובת ה-URL של שרת ה-API של שרת ה-API) ו-TargetEndpoint (שמגדיר את כתובת ה-URL של השירות לקצה העורפי).
ב-Apigee Edge יש הרבה גמישות לבניית התנהגות מתוחכמת בנוסף לדפוס הזה. לדוגמה, אפשר להוסיף מדיניות כדי לקבוע איך ה-API מעבד בקשת לקוח לפני שליחתה לשירות לקצה העורפי, או לשנות את התגובה שהתקבלה מהשירות לקצה העורפי לפני ההעברה ללקוח. אפשר להפעיל שירותים אחרים באמצעות כללי המדיניות בנושא יתרונות מרכזיים של שירותים, להוסיף התנהגות מותאמת אישית על ידי הוספה של קוד JavaScript, ואפילו ליצור שרת proxy ל-API שלא מפעיל שירות לקצה העורפי.
דוגמת עיצוב
מבחינה טכנית, השימוש בנכסי יתרונות מרכזיים של שירות לצורך הפעלת שירות לקצה העורפי בשרת proxy ל-API ללא נתיבים לנקודת קצה (endpoint) של יעד, הוא הכרחי לאובדן של נתוני ניתוח נתונים לגבי הביצועים של השירות החיצוני.
שרת proxy ל-API שלא מכיל נתיבי יעד יכול להיות שימושי במקרים שבהם לא צריך להעביר את הודעת הבקשה ל-TargetEndpoint. במקום זאת, נקודת ה-ProxyEndpoint מבצעת את כל העיבודים הנדרשים. לדוגמה, ProxyEndpoint יכול לאחזר נתונים מחיפוש במאגר המפתחות/ערך של שירות ה-API, ולהחזיר את התגובה בלי להפעיל שירות לקצה העורפי.
אפשר להגדיר נתיב ריק בשרת proxy ל-API, כפי שמוצג כאן:
<RouteRule name="noroute"/>
שרת proxy שמשתמש בנתיב ריק הוא שרת proxy מסוג "ללא יעד", כי הוא לא מפעיל שירות לקצה העורפי של היעד.
מבחינה טכנית אפשר להוסיף יתרונות מרכזיים של שירות לשרת proxy ללא יעד כדי להפעיל שירות חיצוני, כפי שמתואר בדוגמה הבאה:
<!-- /antipatterns/examples/service-callout-no-target-1.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
<Description/>
<FaultRules/>
<PreFlow name="PreFlow">
<Request>
<Step>
<Name>ServiceCallout-InvokeBackend</Name>
</Step>
</Request>
<Response/>
</PreFlow>
<PostFlow name="PostFlow">
<Request/>
<Response/>
</PostFlow>
<Flows/>
<HTTPProxyConnection>
<BasePath>/no-target-proxy</BasePath>
<Properties/>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
<RouteRule name="noroute"/>
</ProxyEndpoint>
עם זאת, שרת ה-proxy לא יכול לספק ניתוח נתונים לגבי אופן הפעולה של השירות החיצוני (כמו זמן עיבוד או שיעורי שגיאות), ולכן קשה להעריך את הביצועים של השירות החיצוני.
השפעה
- אין נתונים זמינים של Analytics לגבי האינטראקציה עם השירות החיצוני ( קודי שגיאה, זמן תגובה, יעד ביצועים וכו')
- כל לוגיקה ספציפית שנדרשת לפני או אחרי ההפעלה של היתרונות המרכזיים של השירות נכללת בלוגיקה הכוללת של שרת ה-proxy, ולכן קשה יותר להבין אותה ולעשות בה שימוש חוזר.
שיטה מומלצת
אם שרת proxy של API מקיים אינטראקציה עם שירות חיצוני אחד בלבד, שרת ה-proxy צריך להיות תואם לדפוס העיצוב הבסיסי, שבו השירות לקצה העורפי מוגדר כנקודת הקצה של היעד של שרת ה-proxy של ה-API. שרת proxy ללא כללי ניתוב לנקודת קצה (endpoint) של יעד לא אמור להפעיל שירות לקצה העורפי באמצעות המדיניות ServiceCallout.
ההגדרות האישיות הבאות של שרת ה-Proxy מטמיעות את אותה התנהגות כמו בדוגמה שלמעלה, אבל פועלות לפי השיטות המומלצות:
<!-- /antipatterns/examples/service-callout-no-target-2.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
<Description/>
<FaultRules/>
<PreFlow name="PreFlow">
<Request/>
<Response/>
</PreFlow>
<PostFlow name="PostFlow">
<Request/>
<Response/>
</PostFlow>
<Flows/>
<HTTPProxyConnection>
<BasePath>/simple-proxy-with-route-to-backend</BasePath>
<Properties/>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
<RouteRule name="default">
<TargetEndpoint>default</TargetEndpoint>
</RouteRule>
</ProxyEndpoint>
כדאי להשתמש בנכסי יתרונות מרכזיים של שירות כדי לתמוך בתרחישים של mashup, במקרים שבהם רוצים להפעיל שירותים חיצוניים לפני או אחרי ההפעלה של נקודת הקצה (endpoint) של היעד. נכסי היתרונות המרכזיים של השירות לא נועדו להחליף את ההפעלה של נקודת הקצה (endpoint) של היעד.