יצירת שרת proxy פשוט ל-API

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

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

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

בסרטון הבא תמצאו סקירה כללית של תהליך היצירה של שרת proxy ל-API.

יצירת שרת proxy ל-API באמצעות ממשק המשתמש

הדרך הקלה ביותר ליצור שרת proxy ל-API היא באמצעות האשף Create Proxy.

Edge

כדי לגשת לאשף יצירת שרת proxy באמצעות ממשק המשתמש של Edge:

  1. נכנסים לחשבון בכתובת apigee.com/edge.
  2. בוחרים באפשרות פיתוח > שרתי proxy ל-API בסרגל הניווט הימני.
  3. לוחצים על +Proxy.

האשף 'יצירת שרת proxy' מציג ומנחה אתכם לאורך השלבים ליצירה ולהוספה של תכונות מינימליות לשרת proxy ל-API.

הדף הראשון של האשף 'יצירת שרת proxy' שבו תתבקשו לבחור באפשרות 'שרת Proxy הפוך', 'שירות SOAP', 'ללא יעד' או 'חבילת Proxy' כדי להתאים אישית את תהליך האשף.

Classic Edge (ענן פרטי)

כדי לגשת לאשף יצירת שרת proxy באמצעות ממשק המשתמש של Classic Edge:

  1. יש להיכנס אל http://ms-ip:9000, כאשר ms-ip הוא כתובת ה-IP או שם ה-DNS של הצומת של שרת הניהול.
  2. בוחרים באפשרות APIs > ממשקי API ל-API בסרגל הניווט העליון.
  3. לוחצים על + API Proxy.

האשף 'יצירת שרת proxy' מציג ומנחה אתכם לאורך השלבים ליצירה ולהוספה של תכונות מינימליות לשרת proxy ל-API.

הדף הראשון של האשף 'יצירת שרת proxy' שבו תתבקשו לבחור באפשרות 'שרת Proxy הפוך', 'שירות SOAP', 'ללא יעד' או 'חבילת Proxy' כדי להתאים אישית את תהליך האשף.

בדף הראשון של האשף אפשר ליצור שרת proxy ל-API מהמקורות הבאים:

סוג תיאור
שרת proxy הפוך (הכי נפוץ)

שרת proxy ל-API שמנתב בקשות נכנסות לשירותים קיימים לקצה העורפי של HTTP. יכול להיות API בפורמט JSON או XML. ראו יצירת שרת proxy הפוך עבור שירות HTTP בהמשך הקטע.

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

שירות SOAP שרת proxy ל-API שנוצר מקובץ WSDL. ראו חשיפת שירות אינטרנט מבוסס SOAP כ-proxy ל-API.
ללא יעד

שרת proxy ל-API ללא קצה עורפי של API ('ללא יעד'). דומה ל- יצירת שרת proxy הפוך עבור שירות HTTP שתואר קודם לכן: חוץ מאשר שלא תציינו ממשק API קיים בזמן הגדרת הפרטים של שרת ה-proxy של ה-API.

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

יעד מתארח

שרת proxy ל-API שמנתב לאפליקציה Node.js שנפרסה בסביבת היעדים המתארחים. סקירה כללית על היעדים המתארחים

העלאת חבילת שרת proxy חבילת Proxy קיימת ל-API (לדוגמה, אחד מProxy ל-API לדוגמה שזמין ב- GitHub.) מידע נוסף מופיע בקטע ייבוא של שרת Proxy ל-API מחבילת 'שרתי proxy ל-API'.

בקטעים הבאים מוסבר איך ליצור שרת proxy ל-API באמצעות כל מקור.

יצירת שרת proxy הפוך עבור שירות HTTP

Edge יוצר שרתי proxy הפוכים על סמך שני פרטי מידע:

  • כתובת ה-URL של השירות לקצה העורפי
  • נתיב URI שמזהה באופן ייחודי את ה-API שייחשף על ידי שרת ה-proxy ל-API כדי אפליקציות לצרכנים

כתובת האתר של שירות הקצה העורפי מייצגת בדרך כלל אפליקציה התומכת בשירות, שנמצאת בבעלות של הארגון. הוא יכול גם להפנות לממשק API שזמין באופן ציבורי. ה-API או השירות יכולים להיות במסגרת בקרה (לדוגמה, אפליקציה פנימית לניהול משאבי אנוש או אפליקציית Rails בענן), או שהיא יכולה להיות ממשק API או שירות של צד שלישי (לדוגמה: Twitter או Instagram).

Edge

  1. נכנסים לאשף 'יצירת שרת proxy', כפי שהוסבר קודם בחלק יצירת שרת proxy ל-API באמצעות ממשק המשתמש בסעיף הזה.
  2. באשף 'יצירת שרת Proxy', לוחצים על היפוך שרת Proxy (הנפוץ ביותר). שפת תרגום ליצור את שרת ה-proxy ממפרט OpenAPI קיים וחוקי, ולוחצים על שימוש במפרט OpenAPI. לפרטים על האפשרות הזו, ראו שימוש במפרטים של OpenAPI ליצירת שרתי proxy בהמשך.
  3. בדף פרטים של האשף, מזינים את הפרטים הבאים.
    שדה תיאור
    שם השם המוצג עבור ה-API שלך. אפשר לציין תווים אלפאנומריים, מקף (-) או קו תחתון (_).
    נתיב בסיס

    קטע ה-URI שמופיע אחרי כתובת http(s)://[host] של שרת proxy ל-API. Edge משתמש ב-URI של הנתיב הבסיסי כדי להתאים ולנתב הודעות בקשה נכנסות לשרת ה-proxy הנכון של ה-API.

    הערה: ערך ברירת המחדל של נתיב הבסיס של שרת ה-proxy ל-API הוא הערך שצוין עבור השדה Name הומר לאותיות קטנות בלבד.

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

    https://[host]/base_path/conditional_flow_path

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

    שימוש בתווים כלליים לחיפוש בנתיבים בסיסיים

    צריך להשתמש בתו כללי לחיפוש אחד או יותר מסוג /*/ בנתיבי הבסיס של שרת proxy ל-API כדי את שרתי ה-proxy ל-API יהיו מוכנים לעתיד. לדוגמה, נתיב בסיסי של /team/*/members מאפשר ללקוחות לקרוא ל-https://[host]/team/blue/members ו-https://[host]/team/green/members בלעדיך צריכים ליצור שרתי proxy חדשים ל-API כדי לתמוך בצוותים חדשים. לתשומת ליבכם: /**/ אינו נתמך.

    תיאור (אופציונלי) תיאור של ה-API.
    יעד (API קיים) כתובת ה-URL של השירות לקצה העורפי ששרת ה-proxy הזה ל-API מפעיל.
  4. בדף Common policies של האשף, קובעים את ההגדרות הבאות:
    • הדרישות להרשאות אבטחה בקטע אבטחה: הרשאה. אפשר לעיין בקטע הוספת אבטחה בהמשך הקטע.
    • תמיכה בשיתוף משאבים בין מקורות (CORS) בקטע אבטחה: דפדפן. אפשר לעיין בקטע הוספת תמיכה ב-CORS בהמשך הקטע הזה.
    • מכסות להגנה על השירות לקצה העורפי מפני תנועה רבה בקטע Quota. ראו מכסות. (האפשרות לא זמינה אם נבחרה הרשאת העברה).
    • אכיפת הגבלת המונטיזציה לארגונים שמפעילים מונטיזציה בקטע מונטיזציה. למידע נוסף, כדאי לעיין בקטע אכיפת מגבלות מונטיזציה בשרתי proxy ל-API.
  5. בדף מארחים וירטואליים באשף, בוחרים את המארחים הווירטואליים שאליהם שרת ה-proxy של ה-API יקשר במהלך הפריסה. למידע נוסף, ראה מידע על מארחים וירטואליים.
  6. בדף Summary, בוחרים את סביבות הפריסה אם רוצים, ולוחצים על Create and Deploy(יצירה ופריסה).

    שרת ה-proxy החדש ל-API נוצר ופרוסות בסביבה שנבחרה.

  7. לוחצים על Edit Proxy (עריכת שרת Proxy) כדי להציג. דף הפרטים של ה-Proxy ל-API.

Classic Edge (ענן פרטי)

  1. נכנסים לאשף 'יצירת שרת proxy', כפי שהוסבר קודם בחלק יצירת שרת proxy ל-API באמצעות ממשק המשתמש בסעיף הזה.
  2. באשף Build a Proxy, בוחרים באפשרות הפוך שרת Proxy (הנפוץ ביותר). שפת תרגום ליצור את שרת ה-proxy ממפרט OpenAPI קיים וחוקי, ולוחצים על שימוש ב-OpenAPI. לפרטים על האפשרות הזו, ראו שימוש במפרטי OpenAPI ליצירת שרתי proxy בהמשך.
  3. לוחצים על הבא.
  4. בדף פרטים של האשף, מזינים את הפרטים הבאים.
    שדה תיאור
    שם ה-Proxy השם שמוצג עבור ה-API.
    נתיב הבסיס של שרת ה-proxy

    הנתיב הבסיסי של שרת ה-proxy הוא קטע של URI אחרי כתובת http(s)://[host] של שרת proxy ל-API. Edge משתמש ב-URI של נתיב הבסיס כדי להתאים ולנתב הודעות של בקשות נכנסות לשרת ה-proxy הנכון של ה-API.

    הערה: להמלצות של Apigee לגבי ניהול גרסאות של API, ראו ניהול גרסאות ב-Web API Design: The Missing Link את הספר הדיגיטלי.

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

    https://[host]/base_path/conditional_flow_path

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

    שימוש בתו כללי לחיפוש בנתיבים בסיסיים

    אפשר להשתמש בתו כללי לחיפוש אחד או יותר מסוג /*/ בנתיבי הבסיס של שרת proxy ל-API כדי את שרתי ה-proxy שלכם יהיו מוכנים לעתיד. לדוגמה, נתיב בסיסי של /team/*/members מאפשר ללקוחות לקרוא ל-https://[host]/team/blue/members ו-https://[host]/team/green/members בלעדיך צריכים ליצור שרתי proxy חדשים ל-API כדי לתמוך בצוותים חדשים. לתשומת ליבכם: /**/ אינו נתמך.

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

    API קיים כתובת ה-URL שפלטפורמת ה-API מפעילה מטעם אפליקציות שקוראות ל-API שלכם דרך את כתובת ה-URL של ה-API של ה-Proxy.
    תיאור התיאור של ה-API.
  5. בדף Security (אבטחה) באשף, קובעים את ההגדרות הבאות:
    • דרישות לאימות אבטחה. אפשר לעיין בקטע הוספת אבטחה בהמשך הקטע.
    • תמיכה בשיתוף משאבים בין מקורות (CORS). אפשר לעיין בקטע הוספת תמיכה ב-CORS בהמשך הקטע הזה.
  6. בדף מארחים וירטואליים של האשף, בוחרים את המארחים הווירטואליים שאליהם שרת ה-proxy של ה-API יקשר במהלך הפריסה. למידע נוסף, ראה מידע על מארחים וירטואליים.
  7. בוחרים את סביבות הפריסה ולוחצים על Build and Deploy(יצירה ופריסה)
    נשלח אישור על כך ששרת ה-proxy החדש ל-API נוצר ופרוסות בסביבה שנבחרה.
  8. לוחצים על הצגת <proxy name> שרת proxy בכלי העריכה כדי להציג דף הפרטים של ה-Proxy ל-API.

ייבוא של שרת proxy ל-API משרת proxy ל-API חבילה

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

בסרטון הזה מוסבר איך יוצרים ומייבאים שרת proxy ל-API משרת proxy ל-API חבילה.

Edge

כדי לייבא שרתי proxy ל-API מחבילת Proxy ל-API:

  1. נכנסים לאשף 'יצירת שרת proxy', כפי שהוסבר קודם בחלק יצירת שרת proxy ל-API באמצעות ממשק המשתמש בסעיף הזה.
  2. לוחצים על העלאת חבילת שרת Proxy.
  3. בדף העלאה של חבילת שרת proxy באשף של שרת ה-proxy, מזינים את הפרטים הבאים.

    שדה תיאור
    חבילת ZIP קובץ ZIP שמכיל את התצורה של שרת ה-proxy ל-API. כדי לנווט לקובץ, גוררים ומשחררים או לוחצים עליו.
    שם השם המוצג עבור ה-API שלך. ברירת המחדל היא השם של קובץ ה-ZIP ללא הסיומת.
  4. לוחצים על הבא.
  5. בדף Summary, בוחרים את סביבות הפריסה אם רוצים, ולוחצים על Create and Deploy(יצירה ופריסה).
    יוצג אישור שמאשר ששרת ה-Proxy החדש ל-API נוצר בהצלחה.
  6. לוחצים על Edit Proxy (עריכת שרת Proxy) כדי להציג. דף הפרטים של ה-Proxy ל-API.

Classic Edge (ענן פרטי)

  1. נכנסים לאשף 'יצירת שרת proxy', כפי שהוסבר קודם בחלק יצירת שרת proxy ל-API באמצעות ממשק המשתמש בסעיף הזה.
  2. באשף Build a Proxy, בוחרים באפשרות Proxy Bundle.
  3. לוחצים על הבא.
  4. בדף פרטים באשף של שרת ה-proxy, מזינים את הפרטים הבאים.

    שדה תיאור
    חבילת ZIP לוחצים על Choose File (בחירת קובץ) ועוברים לקובץ ה-ZIP שמכיל את התצורה של שרת ה-proxy ל-API.
    שם ה-Proxy השם שמוצג עבור ה-API.
  5. בודקים את פרטי ה-build ולוחצים על Build.
    אם הפעולה בוצעה ללא שגיאות, תוצג הודעה ו-Edge פורס באופן אוטומטי את שרת ה-proxy המיובא ל-API בסביבה שנבחרה. בארגון שלך. ה-API שחשוף על ידי שרת ה-proxy של ה-API זמין להפעלה.
  6. לוחצים על הצגת <שם שרת ה-proxy> proxy בעורך כדי להציג דף הפרטים של ה-Proxy ל-API.
  7. כדי לפרוס את שרת ה-proxy, לוחצים על התפריט הנפתח Deployment (פריסה), בוחרים את האפשרות שבה רוצים לפרוס אותה ומגיבים להנחיה.

חשיפת שירות אינטרנט מבוסס SOAP כ-API שרת proxy

באשף 'יצירת שרת proxy', לוחצים על SOAP Service ופועלים לפי האשף כדי ליצור שרת Proxy מיוחד (pass-through) או REST מבוסס-REST לשירות SOAP. למידע נוסף, ראו חשיפה שירות SOAP כשרת proxy ל-API.

הוספת אמצעי אבטחה

בדף Common policies (Edge) או Security (Classic Edge) באשף Create Proxy, בוחרים את סוג הרשאת האבטחה שרוצים להוסיף. הטבלה הבאה מסכמת את האפשרויות הזמינות:

הרשאת אבטחה תיאור
מפתח ממשק API הוספת אימות פשוט של מפתח API לשרת ה-proxy של ה-API והגדרה. בתגובה, פלטפורמת ה-API מוסיפה מדיניות VerifyAPIKey ומדיניות AssignMessage לשרת ה-proxy של ה-API. מדיניות VerifyAPIKey מאמתת מפתחות API שמוצגים על ידי בקשת אפליקציות. מדיניות AssignMessage מסירה את מפתח ה-API, שניתן בקריאה ל-API כפרמטר של שאילתה. הבקשה שהועברה לשרת העורפי.
OAuth 2.0 הוספת אימות מבוסס OAuth 2.0 לשרת ה-proxy של ה-API. מערכת Apigee Edge מוסיף באופן אוטומטי שני כללי מדיניות לשרת ה-proxy ל-API: מדיניות לאימות אסימון גישה ומדיניות נוספת להסרת אסימון הגישה מההודעה לפני ההעברה לשירות לקצה העורפי. כדי ללמוד איך לקבל אסימון גישה, אפשר לעיין במאמר OAuth.
העברה (ללא הרשאה) לא נדרשת הרשאה. הבקשות מועברות לקצה העורפי ללא בדיקות אבטחה ב-Apigee Edge.

הוספת תמיכה ב-CORS

CORS (שיתוף משאבים בין מקורות) הוא מנגנון סטנדרטי שמאפשר לדפדפן אינטרנט לבצע בקשות ישירות לדומיין אחר. תקן CORS מגדיר קבוצה של כותרות HTTP ש-Web שבהם משתמשים בדפדפנים ובשרתים כדי להטמיע תקשורת בין דומיינים.

כדי להוסיף תמיכה ב-CORS ל-API, בוחרים באפשרות הוספת כותרות CORS הדף כללי מדיניות נפוצים (Edge) או אבטחה (Classic Edge) באשף יצירת שרת Proxy.

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

שימוש במפרטי OpenAPI ליצירת שרתי proxy

בסעיף זה מתואר האפשרות 'שימוש ב-OpenAPI' שזמינה ליצירה מ-OpenAPI. מפרט את הסוגים הבאים של שרתי proxy ל-API: הפוך, Node.js או ללא יעד.

מה זה מפרט OpenAPI?

הלוגו של Open API Initiative"יוזמת יוזמת API פתוחה (OAI) מתמקדת ב יצירה, פיתוח וקידום של פורמט תיאור API נייטרלי לספקים שמבוססים על הסוואג מפרט". מידע נוסף על Open API Initiative זמין בכתובת https://openapis.org.

במפרט OpenAPI נעשה שימוש בפורמט סטנדרטי כדי לתאר API ל-RESTful. מפרט OpenAPI כתוב בפורמט JSON או YAML, אבל ניתן גם לקרוא אותו לבני אדם קל לקרוא ולהבין. במפרט מתוארים רכיבים כאלה של API כך: הנתיב הבסיסי, הנתיבים והפעלים, הכותרות, הפרמטרים של השאילתות, הפעולות, סוגי התוכן, התגובה תיאורים ועוד. בנוסף, לרוב משתמשים במפרט OpenAPI ליצירת API התיעוד.

הנה קטע ממפרט OpenAPI שמתאר את שירות היעד המדומה של Apigee: http://mocktarget.apigee.net. עבור מידע נוסף זמין בכתובת https://github.com/apigee/api-platform-samples/tree/master/default-proxies/helloworld/openapi.

openapi: 3.0.0
info:
  description: OpenAPI Specification for the Apigee mock target service endpoint.
  version: 1.0.0
  title: Mock Target API
paths:
  /:
    get:
      summary: View personalized greeting
      operationId: View a personalized greeting
      description: View a personalized greeting for the specified or guest user.
      parameters:
        - name: user
          in: query
          description: Your user name.
          required: false
          schema:
            type: string
      responses:
        "200":
          description: Success
  /help:
    get:
      summary: Get help
      operationId: Get help
      description: View help information about available resources in HTML format.
      responses:
        "200":
          description: Success
...

באמצעות אשף יצירת שרת proxy ניתן לייבא מפרט OpenAPI ולהשתמש בו כדי ליצור שרת proxy ל-API. אחרי יצירת שרת ה-proxy, ניתן להשתמש בממשק המשתמש של Edge כדי להמשיך לפתח אותו באמצעות הוספת מדיניות, הטמעת קוד מותאם אישית וכו' – בדיוק כמו בכל שרת proxy של Edge.

יצירת שרת proxy ל-API ממפרט OpenAPI

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

באשף 'יצירת שרת Proxy', לוחצים על שימוש במפרט OpenAPI ופועלים לפי האשף כדי ליצור שרת Proxy הפוך, או ללא שרת Proxy, ממפרט OpenAPI. מידע נוסף מופיע במאמר יצירת שרת proxy ל-API ממפרט OpenAPI.

בסרטון הזה מוסבר איך ליצור שרת proxy ל-API מתוך מפרט OpenAPI.

עדכון הזרימה בשרת proxy ל-API באמצעות מפרט OpenAPI

אחרי שיוצרים שרת proxy ל-API ממפרט OpenAPI, אם משנים את המפרט ומוסיפים נתיבי משאבים, אפשר להשתמש במפרט כדי להוסיף את התהליכים המותנים המשויכים לשרת ה-proxy של ה-API.

כדי לעדכן את הזרימה בשרת proxy ל-API באמצעות מפרט OpenAPI:

  1. מוסיפים את נתיבי המשאבים החדשים למפרט OpenAPI. ראו עריכה של מפרט OpenAPI קיים.
  2. פותחים את ה-API Proxy בממשק המשתמש ולוחצים על הכרטיסייה פיתוח.
  3. בכלי הניווט, לוחצים על הסמל + לצד נקודת הקצה של שרת ה-proxy שרוצים לעדכן.
    תיפתח תיבת הדו-שיח 'תהליך מותנה חדש'.
  4. לוחצים על האפשרות From OpenAPI אם היא עדיין לא נבחרה.
    אם במפרט OpenAPI יש משאבים שאין להם זרימה מותנית תואמת בשרת ה-proxy של ה-API, הם יופיעו בתיבת הדו-שיח, כמו באיור הבא. משאבים שלא מיוצגים כתהליכים בשרת ה-proxy הנוכחי ל-API. הדוגמה הזו כוללת /loveapis, /ip, /json, ו- /xml.
  5. בוחרים את כל המשאבים שרוצים להוסיף להם תהליך מותנה.
  6. לוחצים על הוספה.

התהליכים המותנים יתווספו לשרת ה-proxy של ה-API.

יצירת גרסה חדשה של שרת proxy ל-API

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

Edge

כדי ליצור גרסה חדשה של שרת proxy ל-API באמצעות ממשק המשתמש של Edge:

  1. נכנסים לחשבון בכתובת apigee.com/edge.
  2. בוחרים באפשרות פיתוח > שרתי proxy ל-API בסרגל הניווט הימני.
  3. ברשימה, לוחצים על שרת ה-proxy ל-API שרוצים להעתיק.
  4. בוחרים באפשרות Project > (פרויקט >) שמירה כגרסה חדשה.

Classic Edge (ענן פרטי)

כדי ליצור גרסה חדשה של שרת proxy ל-API באמצעות ממשק המשתמש של Classic Edge:

  1. יש להיכנס אל http://ms-ip:9000, כאשר ms-ip הוא כתובת ה-IP או שם ה-DNS של הצומת של שרת הניהול.
  2. בוחרים באפשרות APIs > ממשקי API ל-API בסרגל הניווט העליון.
  3. ברשימה, לוחצים על שרת ה-proxy ל-API שרוצים להעתיק.
  4. בוחרים באפשרות Project > (פרויקט >) שמירה כגרסה חדשה.

העתקת שרת proxy ל-API

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

Edge

כדי להעתיק שרת proxy ל-API באמצעות ממשק המשתמש של Edge:

  1. נכנסים לחשבון בכתובת apigee.com/edge.
  2. בוחרים באפשרות פיתוח > שרתי proxy ל-API בסרגל הניווט הימני.
  3. ברשימה, לוחצים על שרת ה-proxy ל-API שרוצים להעתיק.
  4. בוחרים באפשרות Project > (פרויקט >) שמירה כשרת Proxy חדש ל-API.
  5. בתיבת הדו-שיח 'שמירה כשרת Proxy חדש', מזינים את השם של שרת ה-Proxy החדש ל-API.
  6. לוחצים על הוספה.

Classic Edge (ענן פרטי)

כדי להעתיק שרת proxy ל-API באמצעות ממשק המשתמש של Classic Edge:

  1. יש להיכנס אל http://ms-ip:9000, כאשר ms-ip הוא כתובת ה-IP או שם ה-DNS של הצומת של שרת הניהול.
  2. בוחרים באפשרות APIs > ממשקי API ל-API בסרגל הניווט העליון.
  3. ברשימה, לוחצים על שרת ה-proxy ל-API שרוצים להעתיק.
  4. בוחרים באפשרות Project > (פרויקט >) שמירה כשרת Proxy חדש ל-API.
  5. בתיבת הדו-שיח 'שמירה כשרת Proxy חדש', מזינים את השם של שרת ה-Proxy החדש ל-API.
  6. לוחצים על הוספה.

גיבוי של שרת proxy ל-API

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

יצירת שרת proxy ל-API באמצעות ה-API

כדי ליצור שרת proxy ל-API באמצעות ה-API, אפשר לעיין במאמר API proxy ל-API.