הפנייה למאפייני נקודת קצה (endpoint)

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

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

מאפייני תעבורה נקודת קצה (Targetendpoint)

הרכיב HTTPTargetConnection בהגדרות של TargetEndpoint מגדיר קבוצה של HTTP מאפייני התעבורה. אפשר להשתמש במאפיינים האלה כדי להגדיר הגדרות ברמת התעבורה.

המאפיינים מוגדרים ברכיבי HTTPTargetConnection של targetEndpoint באופן הבא:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <Properties>
      <Property name="supports.http10">true</Property>
      <Property name="request.retain.headers">User-Agent,Referer,Accept-Language</Property>
      <Property name="retain.queryparams">apikey</Property>
    </Properties>
    <CommonName>COMMON_NAME_HERE</CommonName>
  </HTTPTargetConnection>
</TargetEndpoint>

נכס העברה TargetEndpoint מפרט

שם הנכס ערך ברירת מחדל תיאור
keepalive.timeout.millis 60000 הזמן הקצוב לתפוגה של חיבור לא פעיל עבור חיבור היעד במאגר החיבורים. אם החיבור במאגר לא פעיל מעבר למגבלה שצוינה, אז החיבור נסגר.
connect.timeout.millis

3000

הזמן הקצוב לתפוגה של חיבור ליעד. Edge מחזיר קוד הסטטוס HTTP 503 אם יש חיבור הזמן הקצוב לתפוגה. במקרים מסוימים ייתכן שיוחזר קוד סטטוס HTTP 504 כאשר LoadBalancer משמש בהגדרת targetServer והזמן שהוקצב פג.

io.timeout.millis 55000

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

  • אם תם הזמן הקצוב לתפוגה במהלך כתיבת בקשת ה-HTTP, 408, Request Timeout מוחזר.
  • אם תם הזמן הקצוב לתפוגה במהלך קריאת תגובת ה-HTTP, 504, Gateway Timeout מוחזר.

הערך הזה צריך תמיד להיות קטן מהערך של נכס proxy_read_timeout של המארח הווירטואלי.

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

מידע נוסף זמין במאמר הגדרה של io.timeout.millis ו-api.timeout for Edge לקבלת מידע נוסף.
supports.http10 true אם הערך הוא true והלקוח שולח בקשה מסוג 1.0, גם היעד נשלח עם הערך 1.0. בקשה. אחרת, בקשת 1.1 נשלחת ליעד.
supports.http11 true אם הערך הוא true והלקוח שולח בקשת 1.1, גם היעד נשלח מסוג 1.1 אחרת, בקשת 1.0 תישלח ליעד.
use.proxy true אם המדיניות מוגדרת לערך true, והגדרות של שרת proxy נקבעות http.properties (פריסות בארגון בלבד), ואז טירגוט של חיבורים מוגדרים להשתמש בשרת ה-proxy שצוין.
use.proxy.tunneling true אם המדיניות מוגדרת לערך true, והגדרות של שרת proxy נקבעות http.properties (פריסות בארגון בלבד), ואז טירגוט מוגדרים להשתמש במנהרה שצוינה. אם היעד משתמש ב-TLS/SSL, אז האפשרות המערכת מתעלמת מהמאפיין הזה, וההודעה תמיד נשלחת דרך מנהרה.
enable.method.override false ל-method של ה-HTTP שצוינה, מגדיר כותרת X-HTTP-Method-Override על את הבקשה היוצאת לשירות היעד. לדוגמה, <Property name="GET.override.method">POST</Property>.
*.override.method לא רלוונטי ל-method של ה-HTTP שצוינה, מגדיר כותרת X-HTTP-Method-Override על של הבקשה היוצאת. לדוגמה, <Property name="GET.override.method">POST</Property>.
request.streaming.enabled false

כברירת מחדל (false), מטענים ייעודיים (payloads) של בקשות HTTP מוקראים למאגר נתונים זמני וכללי מדיניות יכול לפעול על המטען הייעודי (payload) כמצופה. במקרים שבהם מטענים ייעודיים (payloads) גדולים מ- גודל מאגר הנתונים הזמני (10MB), אפשר להגדיר ל-true. כשהערך הוא true, מטענים ייעודיים (payloads) של בקשות HTTP לא נקראים למאגר נתונים זמני; הם בסטרימינג כפי שהוא אל נקודת הקצה של היעד. במקרה הזה, כל מדיניות שפועלת מתבצעת עקיפה של המטען הייעודי (payload) בתהליך הבקשה של TargetEndpoint. למידע נוסף, אפשר לעיין בסטרימינג של בקשות ותגובות.
response.streaming.enabled false

כברירת מחדל (false), מטענים ייעודיים (payloads) של תגובת HTTP מוקראים למאגר נתונים זמני וכללי מדיניות יכול לפעול על המטען הייעודי (payload) כמצופה. במקרים שבהם מטענים ייעודיים (payloads) גדולים מ- גודל מאגר הנתונים הזמני (10MB), אפשר להגדיר ל-true. במצב true, מטענים ייעודיים (payloads) של תגובת HTTP לא נקראים למאגר נתונים זמני; הם מועבר כפי שהוא לזרימת התגובה של ProxyEndpoint. במקרה הזה, כל מדיניות מתבצעת עקיפה של המטען הייעודי (payload) בתהליך התגובה של TargetEndpoint. עוד באותו הקשר בקשות בסטרימינג ו תשובות מדויקות.
success.codes לא רלוונטי

כברירת מחדל, Apigee Edge מתייחסת לקוד HTTP 4XX או 5XX כשגיאות, והוא מתייחס לקוד HTTP 1XX, 2XX ו-3XX. התכונה הזו מאפשרת הגדרה מפורשת של קודי הצלחה, עבור לדוגמה, 2XX, 1XX, 505 מתייחס לכל קוד תגובה של HTTP, 100, 200 ו-505 בתור להצלחה.

הגדרת המאפיין הזה מחליפה את ערכי ברירת המחדל. לכן, אם רוצים להוסיף קוד HTTP 400 לרשימה של קודי ברירת המחדל להצלחה, מגדירים את המאפיין הזה כך:

&lt;Property name="הצלחה.codes">1XX,2XX,3XX,400</Property>

אם רוצים שהמערכת תתייחס רק לקוד HTTP 400 כקוד הצלחה, צריך להגדיר את המאפיין כ:

&lt;Property name="הצלחה.codes">400</Property>

כשמגדירים את קוד ה-HTTP 400 כקוד ההצלחה היחיד, הקודים 1XX, 2XX ו-3XX כאל כשלים.
compression.algorithm לא רלוונטי כברירת מחדל, Apigee Edge מעבירה בקשות ליעד באמצעות אותו סוג דחיסה בתור בקשת הלקוח. אם הבקשה התקבלה מלקוח באמצעות, לדוגמה, gzip דחיסת נתונים, ואז Apigee Edge מעביר את הבקשה לטירגוט באמצעות דחיסת gzip. אם המיקום התגובה שהתקבלה מהיעד משתמשת ב-deflate, ולאחר מכן ב-Apigee Edge מעביר את התשובה אל הלקוח באמצעות deflate. הערכים הנתמכים הם:
  • gzip: תמיד לשלוח הודעה באמצעות דחיסת gzip
  • deflate: שליחת הודעה תמיד באמצעות דחיסת נתונים מסוג deflate
  • ללא: שליחת ההודעה תמיד ללא דחיסת נתונים

מאמרים קשורים: האם ב-Apigee יש תמיכה בדחיסה או בביטול דחיסה באמצעות דחיסת GZIP או deflate?
request.retain.headers.
enabled		 true כברירת מחדל, כל כותרות ה-HTTP נשמרות ב-Apigee Edge תמיד בהודעות יוצאות. כשההגדרה מוגדרת עד true, כל כותרות ה-HTTP שקיימות בבקשה הנכנסת מוגדרות בקשה יוצאת.
request.retain.headers לא רלוונטי מגדירה כותרות HTTP ספציפיות מהבקשה שצריך להגדיר בקשה לשירות היעד. לדוגמה, כדי לבצע העברה של User-Agent , צריך להגדיר את הערך של request.retain.headers כ-User-Agent. יש לציין כמה כותרות HTTP כרשימה שמופרדת בפסיקים, לדוגמה, User-Agent,Referer,Accept-Language הנכס הזה מבטל את request.retain.headers.enabled אם request.retain.headers.enabled מוגדר ל-false, כל הכותרת שמצוינת הנכס request.retain.headers עדיין מוגדר בהודעה היוצאת.
response.retain.headers.
enabled		 true כברירת מחדל, כל כותרות ה-HTTP נשמרות ב-Apigee Edge תמיד בהודעות יוצאות. כשההגדרה מוגדרת אל true, כל כותרות ה-HTTP שנמצאות בתגובה הנכנסת מהיעד השירות מוגדר בתגובה היוצאת לפני שהוא מועבר ל-ProxyEndpoint.
response.retain.headers לא רלוונטי מגדירה כותרות HTTP ספציפיות מהתגובה שצריך להגדיר ביציאה היוצאת תגובה לפני שהיא מועברת ל-ProxyEndpoint. לדוגמה, כדי לבצע העברה של הכותרת Expires, הגדרת הערך של response.retain.headers כ- Expires. יש לציין כמה כותרות HTTP כרשימה שמופרדת בפסיקים, עבור לדוגמה, Expires,Set-Cookie. הנכס הזה מבטל את response.retain.headers.enabled אם המיקום response.retain.headers.enabled מוגדר ל-false, כל הכותרות שצוינו במאפיין response.retain.headers עדיין מוגדרים הודעה יוצאת.
retain.queryparams.
enabled		 true כברירת מחדל, Apigee Edge תמיד שומרת את כל הפרמטרים של השאילתות בבקשות יוצאות. מתי מוגדר ל-true, כל הפרמטרים של שאילתה שמופיעים בבקשה הנכנסת מוגדרים על את הבקשה היוצאת לשירות היעד.
retain.queryparams לא רלוונטי הגדרת פרמטרים ספציפיים של שאילתה להגדרה בבקשה היוצאת. לדוגמה, כדי כוללים את פרמטר השאילתה apikey מהודעת הבקשה, מגדירים retain.queryparams עד apikey. יש כמה פרמטרים של שאילתות מצוין כרשימה שמופרדת בפסיקים, לדוגמה apikey,environment. הזה המאפיין הזה מבטל את retain.queryparams.enabled.

מאפייני העברה של Proxy Endpoint

רכיבי HTTPTargetConnection של ProxyEndpoint מגדירים קבוצה של מאפייני העברה ב-HTTP. האלה אפשר להשתמש במאפיינים כדי לקבוע הגדרות ברמת התעבורה.

המאפיינים מוגדרים ברכיבי HTTPProxyConnection של ProxyEndpoint באופן הבא:

<ProxyEndpoint name="default">
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <Properties>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
    <VirtualHost>default</VirtualHost>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>

מידע נוסף על מארחים וירטואליים זמין במאמר מידע על מארחים וירטואליים.

נכס העברה של Proxy Endpoint מפרט

שם הנכס ערך ברירת מחדל תיאור
X-Forwarded-For false כשהיא מוגדרת לערך true, כתובת ה-IP של המארח הווירטואלי מתווספת לבקשה היוצאת בתור של כותרת ה-HTTP X-Forwarded-For.
request.streaming.
enabled		 false כברירת מחדל (false), מטענים ייעודיים (payloads) של בקשות HTTP מוקראים במאגר זמני, וכללי מדיניות שיכולים לפעול על המטען הייעודי (payload) כמצופה. במקרים שבהם מטענים ייעודיים גדולים יותר מאגר נתונים זמני (10MB), אפשר להגדיר ל-true. כשהערך הוא true, מטענים ייעודיים (payloads) של בקשות HTTP לא נקראים למאגר נתונים זמני; הם מועברים כפי שהם בתהליך הבקשה של TargetEndpoint. במקרה הזה, כל מדיניות שפועלת במטען הייעודי (payload) בתהליך הבקשה של ProxyEndpoint. למידע נוסף, אפשר לעיין בסטרימינג של בקשות ותגובות.
response.streaming.
enabled		 false כברירת מחדל (false), מטענים ייעודיים (payloads) של תגובת HTTP מוקראים למאגר נתונים זמני וכללי מדיניות יכול לפעול על המטען הייעודי (payload) כמצופה. במקרים שבהם מטענים ייעודיים (payloads) גדולים מ- גודל מאגר הנתונים הזמני (10MB), אפשר להגדיר ל-true. במצב true, מטענים ייעודיים (payloads) של תגובת HTTP לא נקראים למאגר נתונים זמני; הם בסטרימינג כפי שהוא ללקוח. במקרה הזה, כל מדיניות שפועלת על המטען הייעודי (Payload) בקובץ בוצע עקיפה של תהליך התגובה של ProxyEndpoint. למידע נוסף, אפשר לעיין בסטרימינג של בקשות ותגובות.
compression.algorithm לא רלוונטי

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

  • gzip: תמיד לשלוח הודעה באמצעות דחיסת gzip
  • deflate: שליחת הודעה תמיד באמצעות דחיסת נתונים מסוג deflate
  • ללא: שליחת ההודעה תמיד ללא דחיסת נתונים

מאמרים קשורים: האם ב-Apigee יש תמיכה בדחיסה או בביטול דחיסה באמצעות דחיסת GZIP או deflate?
api.timeout לא רלוונטי

הגדרת זמן קצוב לתפוגה לשרתי proxy ל-API ספציפיים

תוכלו להגדיר שרתי proxy ל-API, גם כאלה עם סטרימינג מופעל, כדי שיפוג אחרי פרק זמן מוגדר עם סטטוס 504 Gateway Timeout. התרחיש לדוגמה העיקרי הוא לקוחות שיש להם שרתי proxy ל-API שנדרשים זמן רב יותר לביצוע. לדוגמה, נניח שאתם צריכים שרתי proxy ספציפיים כדי להפסיק את הזמן הקצוב לתפוגה דקות. אלה ההנחיות לשימוש ב-api.timeout.

  1. קודם כל צריך להגדיר את מאזן העומסים, הנתב ומעבד ההודעות אחרי שלוש דקות.
  2. לאחר מכן הגדירו את שרתי ה-proxy הרלוונטיים כך שהזמן הקצוב לתפוגה יסתיים בשעה שלוש דקות. ציון הערך ב- אלפיות שנייה. לדוגמה: <Property name="api.timeout">180000</Property>
  3. עם זאת, חשוב לשים לב שהגדלת הזמן הקצוב לתפוגה של המערכת עלולה לגרום לבעיות בביצועים. כי כל שרתי ה-proxy ללא ההגדרה api.timeout משתמשים בטעינה החדשה, הגבוהה יותר הזמן הקצוב לתפוגה של מאזן, נתב ומעבד הודעות. לכן צריך להגדיר שרתי proxy אחרים ל-API לא נדרשים זמנים ארוכים יותר קצובים לתפוגה כדי להשתמש בזמנים קצרים יותר. לדוגמה, הפקודה הבאה מגדירה זמן קצוב לתפוגה של שרת proxy ל-API אחרי דקה:
    <Property name="api.timeout">60000</Property>

לא ניתן להגדיר את הנכס הזה באמצעות משתנה.

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

מידע נוסף זמין במאמר הגדרה של io.timeout.millis ו-api.timeout for Edge לקבלת מידע נוסף.

הגדרה של io.timeout.millis ו-api.timeout ל-Edge

ב-Edge, הפעולה io.timeout.millis ו-api.timeout קשורות. בכל בקשה שנשלחת לשרת proxy של API:

  1. הנתב שולח את ערך הזמן הקצוב לתפוגה למעבד ההודעות. ערך הזמן הקצוב של הנתב הוא אחד הערך של proxy_read_timeout שהוגדר על ידי המארח הווירטואלי המטפל בבקשה, או ערך ברירת המחדל של הזמן הקצוב לתפוגה של 57 שניות.
  2. לאחר מכן, מעבד ההודעות מגדיר את api.timeout:
    1. אם api.timeout לא מוגדר ברמת שרת ה-proxy, יש להגדיר אותו לזמן הקצוב לתפוגה של הנתב.
    2. אם api.timeout מוגדר ברמת שרת ה-proxy, יש להגדיר אותו במעבד ההודעות לערך קטן יותר מהזמן הקצוב של הנתב או מהערך של api.timeout.

  3. הערך של api.timeout מציין את משך הזמן המקסימלי שיש לשרת proxy ל-API יופעל מבקשת ה-API לתשובה.

    אחרי ההפעלה של כל מדיניות ב-proxy ל-API, או לפני שמעבד ההודעות שולח את הבקשה לנקודת הקצה (endpoint) של היעד, מעבד ההודעות מחשב (api.timeout – הזמן שחלף מתחילת הבקשה). אם הערך קטן מאפס, פג התוקף של משך הזמן המקסימלי לטיפול בבקשה. מעבד ההודעות מחזיר 504.

  4. הערך של io.timeout.millis מציין את משך הזמן המקסימלי שנקודת הקצה בקמפיין היעד חייב להגיב.

    לפני החיבור לנקודת קצה (endpoint) של יעד, מעבד ההודעות קובע (api.timeout - הזמן שחלף מתחילת הבקשה) ו-io.timeout.millis. לאחר מכן היא מגדירה את io.timeout.millis לערך הזה.

    • אם תם הזמן הקצוב לתפוגה במהלך כתיבת בקשת ה-HTTP, 408, Request Timeout מוחזר.
    • אם תם הזמן הקצוב לתפוגה במהלך קריאת תגובת ה-HTTP, 504, Gateway Timeout מוחזר.

מידע על ScriptTarget לאפליקציות ב-Node.js

הרכיב ScriptTarget משמש לשילוב אפליקציה של Node.js בשרת ה-proxy. עבור למידע על השימוש ב-Node.js וב-ScriptTarget, ראו:

מידע על נקודות קצה של HostedTarget

תג <HostedTarget/> ריק מורה ל-Edge להשתמש כיעד ב-Node.js שנפרסה בסביבת היעדים המתארחים. פרטים נוספים זמינים במאמר סקירה כללית של היעדים המתארחים