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

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

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

נכסי העברה של TargetEndpoint

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

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

<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 אם תם הזמן הקצוב לתפוגה של החיבור.
io.timeout.millis 55000

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

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

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

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

מידע נוסף זמין במאמר הגדרת io.timeout.millis ו-api.timeout ל-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 בשיטת ה-HTTP שצוינה, מגדירים את הכותרת X-HTTP-Method-Override בבקשה היוצאת לשירות היעד. לדוגמה, <Property name="GET.override.method">POST</Property>
*.override.method לא רלוונטי בשיטת ה-HTTP שצוינה, מגדירים את הכותרת X-HTTP-Method-Override בבקשה היוצאת. לדוגמה, <Property name="GET.override.method">POST</Property>
request.streaming.enabled false

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

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

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

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

<Property name="Success.codes"> 1XX,2XX,3XX,400</Property>

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

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

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

מומלץ לעיין גם במידע הבא: האם Apigee תומכת בדחיסה או בביטול דחיסה עם דחיסת GZIP/deflate?
request.retain.headers.
enabled		 true כברירת מחדל, Apigee Edge תמיד שומר את כל כותרות ה-HTTP בהודעות יוצאות. אם היא מוגדרת לערך 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 כברירת מחדל, Apigee Edge תמיד שומר את כל כותרות ה-HTTP בהודעות יוצאות. אם המדיניות מוגדרת לערך 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.

מאפייני העברה של ProxyEndpoint

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

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

<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>

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

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

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

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

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

מומלץ לעיין גם במידע הבא: האם Apigee תומכת בדחיסה או בביטול דחיסה עם דחיסת GZIP/deflate?
api.timeout לא רלוונטי

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

אפשר להגדיר שרתי proxy ל-API, גם אם האפשרות סטרימינג מופעלת בהם, כדי להפסיק את הפעילות לאחר זמן מוגדר עם סטטוס 504 Gateway Timeout. התרחיש העיקרי לדוגמה מיועד ללקוחות שיש להם שרתי proxy של API שההפעלה שלהם נמשכת זמן רב יותר. לדוגמה, נניח שאתם צריכים שרתי proxy ספציפיים כדי לסיים את הזמן הקצוב לתפוגה של 3 דקות. כך משתמשים ב-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 ל-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 מופעלת, או לפני שמעבד ההודעות שולח את הבקשה לנקודת הקצה של היעד, מעבד ההודעות מחשב (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 שנפרסה בסביבת יעדים מתארחים. לפרטים נוספים אפשר לעיין בסקירה הכללית על יעדים מתארחים.