משתני בקשה ותגובה

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

כששולחים בקשה לשרת proxy ל-API, אפשר להעביר כל אחד מפרטי המידע הבאים או את כולם: בהתאם לאופן שבו מוגדר ה-Proxy ל-API:

  • כותרות של בקשות
  • פרמטרים של שאילתות
  • נתוני טופס
  • מטענים ייעודיים (payloads) של XML או JSON
  • מזהי URI של משאבים

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

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

איך נתוני הבקשות מועברים לקצה העורפי שרת?

בתמונה הבאה מוצגת הגדרה של שרת proxy ל-API:

בקשה מלקוח HTTP שעובר דרך נקודת הקצה של שרת ה-proxy אל נקודת הקצה (endpoint) של היעד בקצה העורפי כדי להגיע לשירות ה-HTTP. הוספנו דוגמאות לנקודת הקצה של שרת proxy ולנקודת הקצה של היעד.

לשרת ה-Proxy ל-API:

  • מארח וירטואלי של שרת proxy ל-API: "ברירת מחדל"
  • הדומיין מוגדר על ידי המארח הווירטואלי: "http://myOrg-prod.apigee.net"
  • נתיב הבסיס של שרת ה-proxy: /v1/weather"
  • נקודת הקצה (TargetEndpoint) שצוינה לפי כלל הנתיב: "default"
  • כתובת ה-URL של יעד: "http://weather.yahooapis.com"

אפליקציית לקוח שולחת בקשת GET לשרת ה-proxy ל-API באמצעות הפקודה הבאה: הפקודה curl:

curl -X GET http://myOrg-prod.apigee.net/v1/weather/forecastrss?w=12797282

שימו לב שהבקשה הזו מכילה את המשאב 'תחזיות' ופרמטר שאילתה אחד, w Edge מנתח את הבקשה בתור שמוצגת בהמשך, ומקצה למשתני זרימה חלקים מהבקשה:

{request.verb} {proxy.basepath}/{proxy.pathsuffix}?{request.querystring}

משתני הזרימה מוגדרים עם הערכים הבאים:

  • request.verb: "GET"
  • proxy.basepath: "/v1/weather"
  • proxy.pathsuffix: "תחזיות"
  • request.querystring: "w=12797282"

לאחר מכן, נקודת הקצה (TargetEndpoint) שולחת בקשה לשירות לקצה העורפי באמצעות מידע בקשה:

{request.verb} {target.basepath}/{proxy.pathsuffix}?{request.querystring}

שימו לב איך הפרמטרים של המשאב והשאילתה שצוינו בבקשה נכללים באופן אוטומטי בבקשה לשרת העורפי. מההגדרה של נקודת הקצה (TargetEndpoint), הבקשה בצורה הבאה:

curl -X GET http://weather.yahooapis.com/forecastrss?w=12797282

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

curl -X GET -H 'Content-type:application/xml' http://myOrg-prod.apigee.net/v1/weather/forecastrss?w=12797282

או בקשה להוספת כותרת ונתוני טופס בטופס הבא:

curl -X POST -H "Content-type:application/json" -d \
  '{"email" : "janetutorialxml@example.com",
    "firstName" : "Jane",
    "lastName" : "Tutorial",
    "userName" : "jtutorialxml"
  }' \
  http://myOrg-prod.apigee.net/v1/register/user

בשתי הדוגמאות, הכותרות ונתוני הטפסים מועברים ללא שינוי לשירות לקצה העורפי. מיוצגות על ידי משתני זרימה כמו request.headers.count request.headers.names. נתוני הטופס מיוצגים על ידי משתני זרימה, כמו request.formparam.count וגם request.formparam.names

איך מוחזרים נתוני תגובות?

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

גישה לנתוני הבקשות והתשובות ב: שרת proxy ל-API

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

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

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

בקשות גישה להודעות

אתם יכולים להשתמש בכללי המדיניות כדי לגשת לחלקים של הודעות בקשה ולשנות אותם. החלקים האלה כוללים:

  • כותרות
  • פרמטרים של שאילתה
  • פרמטרים של טופס
  • כתובת IP של המקור
  • גוף הודעת HTTP

בתהליך רגיל, לאחר עיבוד הבקשה, שרת ה-proxy שולח את הטרנספורמציה בקשה ליעד.

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

גישה להודעות מהתשובות

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

שרת ה-proxy מקבל הודעת תגובה, ואז מחיל עליה סדרת כללי מדיניות, בהתאם תנאים להערכת התגובה, שיכולים לשנות או לשנות את התשובה.

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

כללי מדיניות נפוצים לגישה למשתני זרימה

Edge מגדיר מספר כללי מדיניות שבהם אפשר להשתמש כדי לעבד את נתוני הבקשה והתשובות. האלה המדיניות כוללת:

  • AssignMessage policy: יוצר או משנה הודעות תגובה או בקשת HTTP במהלך שרת proxy ל-API . בנוסף, יוצר ומאכלס משתני זרימה חדשים.
  • PolicyVariables: חילוץ תוכן מהודעות, כולל כותרות, נתיבי URI, מטענים ייעודיים (payloads) ו פרמטרים של שאילתה לשימוש בהצהרת תנאי. לאחר מכן המדיניות מחילה תבנית טקסט על תוכן ההודעה וכשמוצאים התאמה מגדיר משתנה ייעודי.
  • מדיניות JSONtoXML ומדיניות XMLtoJSON: ממירה הודעות מ-JavaScript Object Notation (JSON) לשפת סימון הניתנת להרחבה (XML) או להפך.
  • מדיניות JavaCallout, מדיניות JavaScript, מדיניות PythonScript, מדיניותregularExpressionProtection: כללי המדיניות האלה מאפשרים לכתוב סקריפט כדי לגשת למשתני זרימה שמכיל נתונים של בקשות ותגובות.