חשיפת שירות SOAP כשרת proxy של API

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

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

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

יצירת שרת proxy של API ל-RESTful לשירות מבוסס SOAP

בקטע הזה מוסבר איך ליצור שרת proxy של SOAP API עם RESTful באמצעות האפשרות REST to SOAP to REST באשף Build a Proxy (יצירת שרת proxy).

סקירה כללית

האפשרות REST to SOAP to REST מעבדת את ה-WSDL כדי ליצור proxy של API בארכיטקטורת REST. ‫Edge קובע מ-WSDL את הפעולות הנתמכות של השירות, פרמטרים של קלט וכן הלאה. ‫Edge "מנחש" באיזו שיטת HTTP להשתמש לכל פעולה. בדרך כלל, Edge מתרגם פעולות לבקשות GET, שהיתרון שלהן הוא שאפשר לשמור אותן במטמון. בנוסף, Edge מגדיר את נקודת הקצה של היעד בעורף, שיכולה להשתנות בהתאם לפעולת ה-SOAP.

בסוג הזה של פרוקסי, Edge יוצר אוטומטית מפרט OpenAPI, שאפשר להשתמש בו כדי ליצור תיעוד של ה-API.

שלבים בסיסיים

Edge

כדי ליצור פרוקסי של API מבוסס-REST לשירות מבוסס-SOAP באמצעות ממשק המשתמש של Edge:

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

    בוחרים את המקור של ה-WSDL.

    • מכתובת אינטרנט (URL) – מזינים או מדביקים את כתובת ה-URL של ה-WSDL.
    • מהמחשב שלי – העלאת קובץ WSDL מהספרייה המקומית. אם יש תלות בין הקבצים, אפשר להעלות כמה קבצים.
  6. לוחצים על אימות כדי לאמת את ה-WSDL.
  7. מזינים את פרטי השרת הפרוקסי הבאים:
    שדה תיאור
    שם השם שמוצג עבור ה-API. צריך לציין תווים אלפאנומריים, מקף (-) או קו תחתון (_).
    נתיב בסיסי

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

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

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

    https://[host]/base_path/conditional_flow_path

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

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

    כדי להבטיח ששרתי ה-proxy ל-API ימשיכו לפעול גם בעתיד, כדאי להשתמש בתו כללי אחד או יותר של /*/ בנתיבי הבסיס של שרתי ה-proxy ל-API. לדוגמה, נתיב בסיסי של /team/*/members מאפשר ללקוחות לבצע קריאה ל-https://[host]/team/blue/members ול-https://[host]/team/green/members בלי שתצטרכו ליצור שרתי proxy חדשים של API כדי לתמוך בצוותים חדשים. שימו לב: אין תמיכה ב-/**/.
    תיאור (אופציונלי) תיאור של ה-API.
  8. לוחצים על הבא.
  9. בדף Common policies של האשף, מגדירים את האפשרויות הבאות:
  10. בדף WSDL operations (פעולות WSDL), בוחרים את סוג ה-API proxy‏ REST to SOAP to REST (מ-REST ל-SOAP ל-REST).

    מוצגת טבלה עם רשימה של הפעולות ש-Edge 'זיהה' בקובץ WSDL. אתם יכולים לבחור ולהגדיר אילו פעולות תרצו לשלב ב-API proxy. הטבלה מוצגת באיור הבא.

  11. בתפריט הנפתח סוג יציאה, בוחרים את קבוצת הפעולות שרוצים להשתמש בה. ב-WSDL, רכיבי port type מגדירים את הפעולות שאפשר להפעיל בשירות אינטרנט.
  12. אפשר לשנות את הנתיב של פעולה ב-API ל-REST. הנתיב ישמש כשם המשאב בכתובת ה-URL של שרת ה-API proxy.
  13. אפשר לשנות את הפועל (שיטת HTTP) שמשויך לפעולה.
  14. לוחצים על הבא.
  15. בדף Virtual hosts באשף, בוחרים את המארחים הווירטואליים שאליהם שרת ה-proxy של ה-API יקשר כשהוא יופעל. מידע נוסף זמין במאמר מידע על מארחים וירטואליים.
  16. לוחצים על הבא.
  17. בוחרים את סביבות הפריסה ולוחצים על יצירה ופריסה
    נוצר פרוקסי חדש של ה-API והוא נפרס בסביבה שנבחרה.
  18. לוחצים על עריכת ה-proxy כדי להציג את דף הפרטים של ה-API proxy.

‫Classic Edge (ענן פרטי)

כדי ליצור פרוקסי של API ל-RESTful לשירות מבוסס SOAP באמצעות ממשק המשתמש הקלאסי של Edge:

  1. מתחברים אל http://ms-ip:9000, כאשר ms-ip היא כתובת ה-IP או שם ה-DNS של צומת שרת הניהול.
  2. בסרגל הניווט העליון, בוחרים באפשרות APIs > API Proxies.
  3. לוחצים על + API Proxy.
  4. באשף Build a Proxy, בוחרים באפשרות SOAP service.
  5. לוחצים על הבא.
  6. בדף הפרטים, בוחרים באפשרויות הבאות. אחרי שבוחרים WSDL, צריך ללחוץ על אימות.
    בשדה הזה do this
    WSDL

    בוחרים את המקור של ה-WSDL.

    • ‫URL – מזינים את כתובת ה-URL של ה-WSDL שרוצים להשתמש בו.
    • קובץ – בוחרים קובץ WSDL במערכת הקבצים. במקרים שבהם יש קבצים נוספים שתלויים בקובץ הזה, אפשר לבחור את כולם.
    • כתובת URL לדוגמה – בוחרים מתוך רשימה של קובצי WSDL לשירותי אינטרנט שזמינים לכולם. הם שימושיים להתנסות בתכונות של פרוקסי SOAP/API ב-Edge.
    שם שרת ה-Proxy

    השם של ה-proxy שאתם יוצרים.
    נתיב בסיסי של שרת proxy

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

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

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

    https://[host]/base_path/conditional_flow_path

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

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

    כדי להבטיח ששרתי ה-proxy ל-API ימשיכו לפעול גם בעתיד, כדאי להשתמש בתו כללי אחד או יותר של /*/ בנתיבי הבסיס של שרתי ה-proxy ל-API. לדוגמה, נתיב בסיסי של /team/*/members מאפשר ללקוחות לבצע קריאה ל-https://[host]/team/blue/members ול-https://[host]/team/green/members בלי שתצטרכו ליצור שרתי proxy חדשים של API כדי לתמוך בצוותים חדשים. שימו לב: אין תמיכה ב-/**/.
    תיאור תיאור קצר של השרת הפרוקסי.
  7. לוחצים על הבא.
  8. בדף WSDL, בוחרים את סוג ה-API Proxy‏ REST to SOAP to REST.

    מוצגת טבלה עם רשימה של הפעולות ש-Edge 'זיהה' בקובץ WSDL. אתם יכולים לבחור ולהגדיר אילו פעולות תרצו לשלב ב-API proxy. הטבלה מוצגת באיור הבא.

    בדף WSDL operations (פעולות WSDL), סוג ה-API proxy מוגדר כ-REST to SOAP to REST (מ-REST ל-SOAP ל-REST), ובטבלה מוצגת שורה אחת של תוצאות עם הפעולה add.

  9. בעמודה Port Type (סוג הפורט), בוחרים את קבוצת הפעולות שרוצים להשתמש בה. ב-WSDL, רכיבי port type מגדירים את הפעולות שאפשר להפעיל בשירות אינטרנט.
  10. אפשר לשנות את שיטת ה-HTTP שמשויכת לפעולה.

    הערה: דפדפן Edge מנסה לנחש את שיטת ה-HTTP שבה צריך להשתמש בכל פעולה. בדרך כלל עדיף להשתמש ב-GET כי אפשר לשמור במטמון בקשות GET.
  11. אפשר לשנות את הנתיב של ה-API ל-REST לפעולה מסוימת. הנתיב ישמש כשם המשאב בכתובת ה-URL של שרת ה-API proxy.
  12. ממשיכים להקליק על שאר השלבים באשף כדי להוסיף אבטחה, לבחור מארחים וירטואליים וסביבת פריסה.
  13. בדף Build (בנייה), לוחצים על Build and Deploy (בנייה ופריסה). ‫Edge יוצר ופורס את שרת ה-API החדש על סמך ה-WSDL.
  14. עוברים לדף הסיכום של ה-API proxy החדש. הערה: נוצר סט של משאבים על סמך הפעולות שהתגלו בקובץ ה-WSDL.

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

מידע על השרת הפרוקסי הסופי

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

לדוגמה, בצד הבקשה, נעשה שימוש במדיניות AssignMessage כדי להגדיר את כתובת ה-URL של היעד. בצד התגובה, כללי המדיניות מופעלים כדי לשנות את התגובה מ-XML ל-JSON, לחלץ את החלק של גוף ה-SOAP מהתגובה למשתנה ולהגדיר את הודעת התגובה. המדיניות הזו (ואחרות) מתווספת באופן אוטומטי כשיוצרים את ה-proxy.

מפרט OpenAPI: כדי לראות את מפרט OpenAPI שנוצר אוטומטית עבור ה-proxy הזה, צריך להיכנס לכתובת http(s)://[proxy_domain]/[proxy_base_path]/openapi.json. עם זאת, ההמרה לא תמיד מדויקת, כי לא כל הכללים של סכמת XML יכולים להיות מיוצגים במפרט OpenAPI.

יצירת שרת proxy למעבר נתונים לשירות מבוסס SOAP

בקטע הזה מוסבר איך ליצור שרת proxy למעבר נתונים באמצעות האפשרות Pass-Through Proxy (שרת proxy למעבר נתונים) בתיבת הדו-שיח Create New Proxy (יצירת שרת proxy חדש).

סקירה כללית

אפשרות ה-Pass-Through Proxy מאפשרת ליצור שרת proxy שמעביר את הודעת ה-SOAP בבקשה לשירות הקצה העורפי בלי לשנות אותה, וכך קל מאוד ליצור שרת proxy לשירות אינטרנט מבוסס-SOAP. מאחורי הקלעים, Edge מטפל בכל השינויים ופעילויות אחרות בתהליך באופן אוטומטי. לדוגמה, אם הבקשה היא בפורמט JSON, ‏ Edge מבצע המרה להודעת SOAP בפורמט XML תקין עם מרחבי שמות נכונים לפני שהוא שולח אותה לשירות באמצעות POST. באופן דומה, כשהשירות מחזיר תגובת SOAP מבוססת-XML, ‏ Edge מתרגם אותה בחזרה ל-JSON לפני שהוא מחזיר אותה ללקוח. בנוסף, Edge מגדיר את נקודת הקצה של יעד ה-Backend, שיכולה להיות שונה לכל פעולת SOAP.

בסוג הזה של שרת proxy, ‏ Edge מארח את ה-WSDL ויוצר זרימה בשרת ה-proxy כדי לאפשר לכם לגשת אליו. הכתובת של קובץ ה-WSDL שמתארח ב-Edge,‏ http(s)://[proxy_domain]/[proxy_base_path]?wsdl, הופכת לכתובת ה-URL החדשה של נקודת הקצה של השירות עבור לקוחות שקוראים לשירות SOAP דרך ה-proxy.

שלבים בסיסיים

Edge

כדי ליצור שרת proxy למעבר נתונים לשירות מבוסס SOAP באמצעות ממשק המשתמש של Edge:

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

    בוחרים את המקור של ה-WSDL.

    • מכתובת אינטרנט (URL) – מזינים או מדביקים את כתובת ה-URL של ה-WSDL.
    • מהמחשב שלי – העלאת קובץ WSDL מהספרייה המקומית. אם יש תלות בין הקבצים, אפשר להעלות כמה קבצים.
    שם

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

    שימוש בתו כללי בנתיבי בסיס

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

    הערה: נתיב הבסיס של ה-API proxy מוגדר כברירת מחדל לערך שצוין בשדה Name, שהומר לאותיות קטנות, אלא אם עורכים במפורש את התוכן בשדה Base Path.
    תיאור (אופציונלי) תיאור של ה-API.
  6. לוחצים על הבא.
  7. בדף Common policies של האשף, מגדירים את האפשרויות הבאות:
  8. בדף WSDL, בוחרים את סוג שרת ה-proxy של ה-API‏ Pass-Through SOAP.

  9. בתפריט הנפתח סוג יציאה, בוחרים את קבוצת הפעולות שרוצים להשתמש בה. ב-WSDL, רכיבי port type מגדירים את הפעולות שאפשר להפעיל בשירות אינטרנט.
  10. לוחצים על הבא.
  11. בדף Virtual hosts באשף, בוחרים את המארחים הווירטואליים שאליהם שרת ה-proxy של ה-API יקשר כשהוא יופעל. מידע נוסף זמין במאמר מידע על מארחים וירטואליים.
  12. בוחרים את סביבות הפריסה ולוחצים על יצירה ופריסה
    נוצר פרוקסי חדש של API ונפרס בסביבה שנבחרה.
  13. לוחצים על עריכת ה-proxy כדי להציג את דף הפרטים של ה-API proxy.

‫Classic Edge (ענן פרטי)

כדי ליצור שרת proxy למעבר נתונים לשירות מבוסס SOAP באמצעות ממשק המשתמש הקלאסי של Edge:

  1. מתחברים אל http://ms-ip:9000, כאשר ms-ip היא כתובת ה-IP או שם ה-DNS של צומת שרת הניהול.
  2. בסרגל הניווט העליון, בוחרים באפשרות APIs > API Proxies.
  3. לוחצים על + API Proxy.
  4. באשף Build a Proxy, בוחרים באפשרות SOAP service.
  5. לוחצים על הבא.
  6. בדף הפרטים, בוחרים באפשרויות הבאות. אחרי שבוחרים WSDL, צריך ללחוץ על אימות.
    בשדה הזה do this
    WSDL

    בוחרים את המקור של ה-WSDL.

    • כתובת URL – מזינים את כתובת ה-URL של ה-WSDL שרוצים להשתמש בו.
    • קובץ – בוחרים קובץ WSDL במערכת הקבצים. במקרים שבהם יש קבצים נוספים שתלויים בקובץ הזה, אפשר לבחור את כולם.
    • כתובת URL לדוגמה – בוחרים מתוך רשימה של קובצי WSDL לשירותי אינטרנט שזמינים לציבור. הם שימושיים להתנסות בתכונות של פרוקסי SOAP/API ב-Edge.
    שם שרת ה-Proxy

    השם של ה-proxy שאתם יוצרים.
    נתיב בסיסי של שרת proxy נתיב הבסיס של ה-Proxy הוא קטע URI שמזהה באופן ייחודי את ה-API שנחשף על ידי ה-Proxy הזה ל-API. שירותי API משתמשים ב-URI של נתיב הבסיס כדי להתאים ולנתב הודעות בקשה נכנסות לפרוקסי ה-API המתאים. (נתיב הבסיס מצורף לדומיין של ה-API, שנוצר באופן אוטומטי על סמך שם הארגון והסביבה שבה ה-API proxy נפרס). מומלץ לכלול מספר גרסה בשם הפרויקט, לדוגמה, /v1/delayedstockquote. ההגדרה הזו תקבע איך אפליקציות צרכניות יפעילו את ה-API.

    הערה: ערך ברירת המחדל של Proxy Base Path (נתיב בסיס של שרת proxy) הוא הערך שצוין עבור Proxy Name (שם שרת proxy) שהומר לאותיות קטנות, אלא אם עורכים במפורש את התוכן בשדה Proxy Base Path.
    תיאור תיאור קצר של השרת הפרוקסי.

  8. לוחצים על הבא.
  9. בדף WSDL, בוחרים את סוג ה-API proxy‏ Pass-Through SOAP.

    הערה: מוצגת טבלה עם רשימה של כל פעולת WSDL והמטען הייעודי (payload) המתאים של SOAP. זהו מטען הייעודי (payload) שמועבר לשירות SOAP בקצה העורפי.

    בדף WSDL, סוג ה-API proxy מוגדר כ-Pass-Through SOAP, ורשימה של פעולות כמו GetQuote מאורגנת לפי סוג הפורט.
  10. בעמודה Port Type (סוג הפורט), בוחרים את קבוצת הפעולות שרוצים להשתמש בה. ב-WSDL, רכיבי port type מגדירים את הפעולות שאפשר להפעיל בשירות אינטרנט.
  11. ממשיכים להקליק על שאר השלבים באשף כדי להוסיף אבטחה, לבחור מארחים וירטואליים וסביבת פריסה.
  12. בדף Build (בנייה), לוחצים על Build and Deploy (בנייה ופריסה). ‫Edge יוצר ופורס את שרת ה-API החדש על סמך ה-WSDL.

מידע על השרת הפרוקסי הסופי

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

לדוגמה, באיור הבא מוצג החלק Target Endpoint Preflow של שרת proxy מסוג pass-through. בצד הבקשה, נעשה שימוש במדיניות AssignMessage כדי להגדיר את כתובת ה-URL של היעד. בצד התגובה, כללי המדיניות מופעלים כדי לשנות את התגובה מ-XML ל-JSON, לחלץ את החלק של גוף ה-SOAP מהתגובה למשתנה ולהגדיר את הודעת התגובה. המדיניות הזו (ואחרות) נוספת באופן אוטומטי כשיוצרים את ה-proxy.

בתצוגה 'פיתוח', בחלונית Flow, החצים מתארים את הזרימה מהבקשה לתגובה, והסמלים מתארים את המדיניות.

WSDL שמתארח ב-Edge: כדי לראות את ה-WSDL שמתארח ב-Edge ונוצר עבור סוג הפרוקסי הזה, עוברים אל http(s)://[proxy_domain]/[proxy_base_path]?wsdl.

פיתוח מתקדם של שרת proxy מ-SOAP ל-REST

בקטעים הקודמים מוסבר איך ליצור שרת proxy של API מ-SOAP ל-REST באמצעות האשף של שרת proxy של API ב-Edge. עם זאת, אם אתם רוצים שליטה מדויקת יותר על ההמרה מ-SOAP ל-REST, אתם יכולים לעקוף את האוטומציה שמספק האשף ולבנות שרת proxy על ידי הוספה והגדרה ידנית של מדיניות כדי לקבל את ההתנהגות הרצויה. מידע נוסף זמין במאמר הדרכה: יצירה ידנית של שרת proxy של SOAP ל-REST API ב-Apigee Edge.