‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

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

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

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

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

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

Edge

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

נכנסים לכתובת apigee.com/edge.
בסרגל הניווט הימני, בוחרים באפשרות פיתוח > שרתי proxy של API.
לוחצים על +Proxy (שרת proxy).

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

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

ממשק משתמש חדש של Edge (ענן פרטי)

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

נכנסים לממשק המשתמש החדש של Edge בכתובת http://host:3001/edge, כאשר host היא כתובת ה-IP או שם ה-DNS של המארח שבו פועל ממשק המשתמש החדש של Edge.
בסרגל הניווט הימני, בוחרים באפשרות פיתוח > שרתי proxy של API.
לוחצים על +Proxy (שרת proxy).

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

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

סוג	תיאור
שרת proxy הפוך (הכי נפוץ)	proxy ל-API שמנתב בקשות נכנסות לשירותי בק-אנד קיימים של HTTP. יכול להיות API בפורמט JSON או XML. אפשר לעיין בקטע יצירת פרוקסי הפוך לשירות HTTP בהמשך המאמר. לוחצים על Use OpenAPI Spec (שימוש במפרט OpenAPI) כדי ליצור את ה-proxy ממפרט OpenAPI תקין. מידע נוסף על האפשרות הזו מופיע בהמשך הקטע במאמר שימוש במפרטי OpenAPI ליצירת שרתי proxy.
שירות SOAP	proxy ל-API שנוצר מקובץ WSDL. מידע נוסף זמין במאמר חשיפת שירות אינטרנט מבוסס SOAP כ-proxy ל-API.
ללא יעד	‫API proxy ללא קצה עורפי של API ('ללא יעד'). בדומה ליצירת שרת proxy הפוך לשירות HTTP שמתואר למעלה, רק שבמקרה הזה לא מציינים API קיים כשמגדירים את פרטי ה-proxy ל-API. לוחצים על Use OpenAPI Spec (שימוש במפרט OpenAPI) כדי ליצור את ה-proxy ממפרט OpenAPI תקין. מידע נוסף על האפשרות הזו מופיע בהמשך הקטע במאמר שימוש במפרטי OpenAPI ליצירת שרתי proxy.
יעד מתארח	proxy ל-API שמנתב לאפליקציית Node.js שנפרסה בסביבת Hosted Targets. מידע נוסף על יעדים מתארחים
העלאת חבילת שרת proxy	חבילת שרתי proxy ל-API קיימת (לדוגמה, אחת מהדוגמאות לשרתי proxy ל-API שזמינות ב-GitHub). מידע נוסף זמין במאמר בנושא ייבוא של proxy ל-API מחבילת proxy ל-API.

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

יצירת שרת proxy הפוך לשירות HTTP

‫Edge יוצר פרוקסי הפוך על סמך שני פריטי מידע:

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

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

Edge

ניגשים לאשף ליצירת proxy ל-API, כמו שמתואר במאמר יצירת proxy ל-API באמצעות ממשק המשתמש בחלק הקודם של המאמר הזה.
באשף ליצירת שרת proxy, לוחצים על Reverse proxy (הנפוץ ביותר). כדי ליצור את ה-proxy ממפרט OpenAPI קיים ותקין, לוחצים על Use OpenAPI Spec. פרטים על האפשרות הזו מופיעים בקטע שימוש במפרטי OpenAPI ליצירת שרתי proxy בהמשך.

בדף פרטים של אשף ההגדרה, מזינים את הפרטים הבאים.

שדה	תיאור
שם	השם שמוצג עבור ה-API. צריך לציין תווים אלפאנומריים, מקף (-) או קו תחתון (_).
נתיב בסיסי	מקטע URI שמופיע אחרי הכתובת http(s)://[host] של proxy ל-API. ‫Edge משתמש ב-URI של נתיב הבסיס כדי להתאים ולנתב הודעות בקשה נכנסות ל-proxy ל-API המתאים. NOTE: נתיב הבסיס של ה-proxy ל-API מוגדר כברירת מחדל לערך שצוין בשדה `Name`, אחרי המרה לאותיות קטנות. אחרי נתיב הבסיס מופיעות כתובות URL נוספות של משאבים. הנה המבנה המלא של כתובת ה-URL שבה ישתמשו לקוחות כדי להפעיל את proxy ל-API: `https://[host]/base_path/conditional_flow_path` NOTE: נתיב הבסיס חייב להיות ייחודי. אי אפשר לפרוס שני שרתי 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 הזה מפעיל.

בדף Common policies של האשף, מגדירים את האפשרויות הבאות:
- דרישות הרשאת אבטחה בקטע אבטחה: הרשאה. בהמשך הקטע הזה מוסבר איך להוסיף אבטחה.
- תמיכה בשיתוף משאבים בין מקורות (CORS) בקטע אבטחה: דפדפן. בהמשך הקטע מוסבר איך להוסיף תמיכה ב-CORS.
- מכסות להגנה על שירות לקצה העורפי מפני תעבורת נתונים גבוהה בקטע Quota. מידע נוסף על מכסות (האפשרות הזו לא זמינה אם בוחרים באפשרות Pass-through authorization).
- אכיפת הגבלות על מונטיזציה בארגונים שהפעילו מונטיזציה, בקטע מונטיזציה. מידע נוסף על אכיפת מגבלות מונטיזציה בשרתי proxy של API
בדף Virtual hosts של האשף, בוחרים את המארחים הווירטואליים שאליהם proxy ל-API יקשר כשהוא ייפרס. מידע נוסף זמין במאמר בנושא מידע על מארחים וירטואליים.
בדף סיכום, בוחרים את סביבות הפריסה הרצויות ולוחצים על יצירה ופריסה.
נוצר proxy ל-API חדש והוא נפרס בסביבה שנבחרה.
לוחצים על עריכת ה-proxy ל-API כדי להציג את דף הפרטים של ה-proxy ל-API.

ממשק משתמש חדש של Edge (ענן פרטי)

ניגשים לאשף ליצירת proxy ל-API, כמו שמתואר במאמר יצירת proxy ל-API באמצעות ממשק המשתמש בחלק הקודם של המאמר הזה.
באשף ליצירת שרת proxy, לוחצים על Reverse proxy (הנפוץ ביותר). כדי ליצור את ה-proxy ממפרט OpenAPI קיים ותקין, לוחצים על Use OpenAPI Spec. פרטים על האפשרות הזו מופיעים בקטע שימוש במפרטי OpenAPI ליצירת שרתי proxy בהמשך.

בדף פרטים של אשף ההגדרה, מזינים את הפרטים הבאים.

שדה	תיאור
שם	השם שמוצג עבור ה-API. צריך לציין תווים אלפאנומריים, מקף (-) או קו תחתון (_).
נתיב בסיסי	מקטע URI שמופיע אחרי הכתובת http(s)://[host] של proxy ל-API. ‫Edge משתמש ב-URI של נתיב הבסיס כדי להתאים ולנתב הודעות בקשה נכנסות ל-proxy ל-API המתאים. NOTE: נתיב הבסיס של ה-proxy ל-API מוגדר כברירת מחדל לערך שצוין בשדה `Name`, אחרי המרה לאותיות קטנות. אחרי נתיב הבסיס מופיעות כתובות URL נוספות של משאבים. הנה המבנה המלא של כתובת ה-URL שבה ישתמשו לקוחות כדי להפעיל את proxy ל-API: `https://[host]/base_path/conditional_flow_path` NOTE: נתיב הבסיס חייב להיות ייחודי. אי אפשר לפרוס שני שרתי 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 הזה מפעיל.

בדף Common policies של האשף, מגדירים את האפשרויות הבאות:
- דרישות הרשאת אבטחה בקטע אבטחה: הרשאה. בהמשך הקטע הזה מוסבר איך להוסיף אבטחה.
- תמיכה בשיתוף משאבים בין מקורות (CORS) בקטע אבטחה: דפדפן. בהמשך הקטע מוסבר איך להוסיף תמיכה ב-CORS.
- מכסות להגנה על שירות לקצה העורפי מפני תעבורת נתונים גבוהה בקטע Quota. מידע נוסף על מכסות (האפשרות הזו לא זמינה אם בוחרים באפשרות Pass-through authorization).
- אכיפת הגבלות על מונטיזציה בארגונים שהפעילו מונטיזציה, בקטע מונטיזציה. מידע נוסף על אכיפת מגבלות מונטיזציה בשרתי proxy של API
בדף Virtual hosts של האשף, בוחרים את המארחים הווירטואליים שאליהם proxy ל-API יקשר כשהוא ייפרס. מידע נוסף זמין במאמר בנושא מידע על מארחים וירטואליים.
בדף סיכום, בוחרים את סביבות הפריסה הרצויות ולוחצים על יצירה ופריסה.
proxy ל-API חדש נוצר ונפרס בסביבה שנבחרה.
לוחצים על עריכת proxy ל-API כדי להציג את דף הפרטים של proxy ל-API.

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

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

‫

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

Edge

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

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

בדף Upload proxy bundle (העלאת חבילת שרת proxy) באשף שרת ה-proxy, מזינים את הפרטים הבאים.

שדה	תיאור
חבילת ZIP	קובץ ZIP שמכיל את הגדרות ה-proxy ל-API. גוררים ומשחררים את הקובץ או לוחצים כדי לעבור אל הקובץ.
שם	השם שמוצג עבור ה-API. כברירת מחדל, השם הוא שם קובץ ה-ZIP בלי הסיומת.

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

ממשק משתמש חדש של Edge (ענן פרטי)

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

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

בדף Upload proxy bundle (העלאת חבילת שרת proxy) באשף שרת ה-proxy, מזינים את הפרטים הבאים.

שדה	תיאור
חבילת ZIP	קובץ ZIP שמכיל את ההגדרה של proxy ל-API. גוררים ומשחררים את הקובץ או לוחצים כדי לעבור אל הקובץ.
שם	השם שמוצג עבור ה-API. כברירת מחדל, השם הוא שם קובץ ה-ZIP בלי הסיומת.

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

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

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

הוספת אבטחה

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

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

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

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

כדי להוסיף תמיכה ב-CORS ל-API, בוחרים באפשרות Add CORS headers (הוספת כותרות CORS) בדף Common policies (מדיניות נפוצה) באשף ליצירת שרת proxy.

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

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

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

מהו מפרט OpenAPI?

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

מפרט OpenAPI משתמש בפורמט סטנדרטי כדי לתאר API ל-REST. מפרט 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
...

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

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

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

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

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

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

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

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

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

הזרימות המותנות נוספות ל-proxy ל-API.

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

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

Edge

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

נכנסים לכתובת apigee.com/edge.
בסרגל הניווט הימני, בוחרים באפשרות פיתוח > שרתי proxy של API.
ברשימה, לוחצים על ה-proxy ל-API שרוצים להעתיק.
בוחרים באפשרות Project > Save as New Revision (פרויקט > שמירה כגרסה חדשה).

ממשק משתמש חדש של Edge (ענן פרטי)

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

נכנסים לממשק המשתמש החדש של Edge בכתובת http://host:3001/edge, כאשר host היא כתובת ה-IP או שם ה-DNS של המארח שבו פועל ממשק המשתמש החדש של Edge.
בסרגל הניווט הימני, בוחרים באפשרות פיתוח > שרתי proxy של API.
ברשימה, לוחצים על ה-proxy ל-API שרוצים להעתיק.
בוחרים באפשרות Project > Save as New Revision (פרויקט > שמירה כגרסה חדשה).

העתקה של proxy ל-API

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

Edge

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

נכנסים לכתובת apigee.com/edge.
בסרגל הניווט הימני, בוחרים באפשרות פיתוח > שרתי proxy של API.
ברשימה, לוחצים על ה-proxy ל-API שרוצים להעתיק.
בוחרים באפשרות Project > Save as New API Proxy (פרויקט > שמירה כשרת proxy חדש של API).
בתיבת הדו-שיח Save as New Proxy (שמירה כ-Proxy חדש), מזינים את השם של ה-proxy ל-API החדש.
לוחצים על הוספה.

ממשק משתמש חדש של Edge (ענן פרטי)

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

נכנסים לממשק המשתמש החדש של Edge בכתובת http://host:3001/edge, כאשר host היא כתובת ה-IP או שם ה-DNS של המארח שבו פועל ממשק המשתמש החדש של Edge.
בסרגל הניווט הימני, בוחרים באפשרות פיתוח > שרתי proxy של API.
ברשימה, לוחצים על ה-proxy ל-API שרוצים להעתיק.
בוחרים באפשרות Project > Save as New API Proxy (פרויקט > שמירה כשרת proxy חדש של API).
בתיבת הדו-שיח Save as New Proxy (שמירה כ-Proxy חדש), מזינים את השם של ה-proxy ל-API החדש.
לוחצים על הוספה.

גיבוי של proxy ל-API

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

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

במאמר API proxies API מוסבר איך ליצור שרת proxy ל-API באמצעות ה-API.