כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של
Apigee X. מידע
כאן מוסבר איך ליצור שרתי proxy של API עבור שירותי אינטרנט מבוססי SOAP. אפשר ליצור שני סוגים של שרתי proxy של SOAP ב-Edge. אחד מהם יוצר ממשק RESTful לקצה העורפי של שירות SOAP, והשני מבצע העברה של הודעת ה-SOAP לקצה העורפי. שתי הטכניקות מתוארות בנושא זה.
בסרטון הזה מוצגת הדגמה מקצה לקצה של הפיכת שירות SOAP לשירות REST באמצעות Apigee Edge באמצעות אשף שרת ה-proxy של ה-API. עם זאת, אם רוצים יותר שליטה על הטרנספורמציה מ-SOAP ל-REST, אפשר ליצור שרת proxy באמצעות כללי מדיניות. מידע נוסף זמין במדריך: יצירה ידנית של שרת proxy מסוג SOAP-to-REST API ב-Apigee Edge.
יצירת שרת proxy ל-RESTful API לשירות שמבוסס על SOAP
בקטע הזה נסביר איך יוצרים שרת proxy ל-RESTful SOAP API בעזרת האפשרות REST to SOAP to REST באשף בניית ה-Proxy.
סקירה כללית
האפשרות REST to SOAP to REST מעבדת את ה-WSDL כדי ליצור שרת proxy ל-RESTful API. Edge קובעת לפי ה-WSDL את הפעולות הנתמכות, הפרמטרים של הקלט וכו' בשירות. Edge "מנחש" באיזו שיטת HTTP להשתמש בכל פעולה. בדרך כלל, Edge מתרגם פעולות לבקשות GET, מאחר שהיתרון של האפשרות הזו ניתן לשמירה במטמון. Edge גם מגדירה את נקודת הקצה של היעד העורפי, שמשתנה בהתאם לפעולת SOAP.
עבור סוג שרת ה-Proxy הזה, Edge יוצר באופן אוטומטי מפרט OpenAPI, שבו ניתן להשתמש כדי ליצור תיעוד של ממשק ה-API.
שלבים בסיסיים
Edge
כך יוצרים שרת proxy ל-RESTful API לשירות מבוסס SOAP באמצעות ממשק המשתמש של Edge:
- נכנסים לאתר apigee.com/edge.
- בסרגל הניווט הימני, בוחרים באפשרות פיתוח > שרתי proxy של API.
- לוחצים על +שרת Proxy.
- לוחצים על שירות SOAP.
- בדף הפרטים של שרת ה-proxy, מספקים את קובץ ה-WSDL.
שדה התיאור שליחת קובץ WSDL בוחרים את המקור של ה-WSDL.
- מכתובת אינטרנט (כתובת URL) – מזינים או מדביקים את כתובת ה-URL של ה-WSDL.
- מהמחשב שלי – מעלים קובץ WSDL מהספרייה המקומית שלכם. אם יש יחסי תלות, אפשר להעלות מספר קבצים.
- לוחצים על אימות כדי לאמת את ה-WSDL.
- מזינים את הפרטים הבאים לגבי שרת ה-proxy:
שדה התיאור שם השם המוצג של ה-API. צריך לציין תווים אלפאנומריים, מקף (-) או קו תחתון (_). נתיב בסיסי קטע ה-URI שמופיע אחרי הכתובת http(s)://[host] של שרת ה-proxy של ה-API. Edge משתמש ב-URI של הנתיב הבסיסי כדי להתאים ולנתב הודעות נכנסות של בקשות לשרת ה-API המתאים.
הערה: ערך ברירת המחדל של נתיב הבסיס של שרת ה-proxy של ה-API הוא הערך שצוין בשדה
Nameלאחר המרה לאותיות קטנות.אחרי הנתיב הבסיסי מופיעות כתובות URL נוספות של משאבים. זה המבנה המלא של כתובות ה-URL שהלקוחות ישתמשו בהן כדי לקרוא לשרת ה-API של ה-API:
https://[host]/base_path/conditional_flow_pathהערה: הנתיב הבסיסי חייב להיות ייחודי. לא ניתן לפרוס שני שרתי proxy של API עם אותו נתיב בסיס. אם עורכים שרת proxy של API שנפרס ומגדירים את הנתיב הבסיסי לאותו ערך כמו נתיב הבסיס של שרת proxy אחר של API, Edge מבטל באופן אוטומטי את שרת ה-proxy של ה-API כששומרים אותו. לפני שאפשר לפרוס מחדש את שרת ה-API של ה-API, צריך לערוך את הנתיב הבסיסי כך שיהיה ייחודי.
שימוש בתווים כלליים לחיפוש בנתיבים בסיסיים
יש להשתמש בתו כללי לחיפוש
/*/או יותר בנתיבי הבסיס של שרת ה-proxy ל-API, כדי להגן על שרתי ה-proxy של ה-API בעתיד. לדוגמה, נתיב בסיסי של/team/*/membersמאפשר ללקוחות לקרוא ל-https://[host]/team/blue/membersול-https://[host]/team/green/membersבלי שיהיה צורך ליצור שרתי proxy חדשים ל-API כדי לתמוך בצוותים חדשים. לתשומת ליבך:/**/לא נתמך.התיאור (אופציונלי) תיאור של ה-API. - לוחצים על הבא.
- בדף Common policies (כללי מדיניות נפוצים) באשף, מגדירים את הפריטים הבאים:
- דרישות לגבי הרשאת אבטחה בקטע אבטחה: הרשאה. למידע נוסף, ראו הוספת אבטחה.
- תמיכה בשיתוף משאבים בין מקורות (CORS) בקטע אבטחה: דפדפן. למידע נוסף, ראו הוספת תמיכה ב-CORS.
- מכסות להגנה על השירות לקצה העורפי מפני תנועה רבה בקטע מכסה. מידע נוסף זמין בקטע Quotas. (האפשרות הזו לא זמינה אם נבחרה הרשאת העברה).
- בדף פעולות WSDL, בוחרים את סוג שרת ה-API מסוג REST to SOAP to REST.
תופיע טבלה עם הפעולות ש-Edge "גילה" בקובץ WSDL. אפשר לבחור ולהגדיר אילו פעולות רוצים לשלב בשרת ה-API של שרת ה-proxy. הטבלה מוצגת באיור הבא.
- בתפריט הנפתח, בוחרים סוג יציאה כדי לציין באיזו קבוצת פעולות רוצים להשתמש. ב-WSDL, רכיבים מסוג סוג היציאה מגדירים את הפעולות שאפשר לקרוא בשירות אינטרנט.
- אפשר לשנות את הנתיב של API ל-REST עבור פעולה. הנתיב ישמש כשם המשאב בכתובת ה-URL של שרת ה-API של שרת ה-API.
- אפשר לשנות את פועל (שיטת ה-HTTP) המשויכת לפעולה.
- לוחצים על הבא.
- בדף מארחים וירטואליים באשף, בוחרים את המארחים הווירטואליים ששרת ה-proxy של ה-API יקשר אליהם במהלך הפריסה. למידע נוסף, ניתן לעיין במאמר מידע על מארחים וירטואליים.
- לוחצים על הבא.
- בוחרים את סביבות הפריסה ולוחצים על יצירה ופריסה.
שרת ה-API החדש של ה-API נוצר ונפרס בסביבה שנבחרה. - לוחצים על Edit proxy כדי להציג את דף הפרטים של שרת ה-API.
Classic Edge (ענן פרטי)
כך יוצרים שרת proxy ל-RESTful API לשירות מבוסס SOAP באמצעות ממשק המשתמש הקלאסי של Edge:
- נכנסים אל
http://ms-ip:9000. ms-ip הוא כתובת ה-IP או שם ה-DNS של הצומת של שרת הניהול. - בסרגל הניווט העליון, בוחרים באפשרות APIs > API Proxies (ממשקי API > ממשקי API).
- לוחצים על + API Proxy.
- באשף Build a Proxy, בוחרים שירות SOAP.
- לוחצים על הבא.
- בדף 'פרטים', בוחרים באפשרויות הבאות. אחרי הבחירה ב-WSDL, צריך ללחוץ על אימות.
בשדה הזה עשה זאת WSDL בוחרים את המקור של ה-WSDL.
- כתובת URL – מזינים את כתובת ה-URL של ה-WSDL שרוצים להשתמש בו.
- קובץ - בוחרים קובץ WSDL במערכת הקבצים שלכם. במקרים שבהם יש עוד קבצים תלויים, אפשר לבחור את כולם.
- דוגמה לכתובת URL – אפשר לבחור מתוך רשימה של WSDL לשירותי אינטרנט שזמינים לציבור. כדאי לנסות את התכונות של שרת ה-proxy של SOAP/ל-API ב-Edge.
שם שרת Proxy זה השם של שרת ה-proxy שיוצרים.
נתיב בסיס של שרת Proxy קטע ה-URI שמופיע אחרי הכתובת http(s)://[host] של שרת ה-proxy של ה-API. Edge משתמש ב-URI של הנתיב הבסיסי כדי להתאים ולנתב הודעות נכנסות של בקשות לשרת ה-API המתאים.
הערה: ערך ברירת המחדל של נתיב הבסיס של שרת ה-proxy ל-API הוא הערך שצוין בשדה
Nameלאחר המרה לאותיות קטנות.אחרי הנתיב הבסיסי מופיעות כתובות URL נוספות של משאבים. זה המבנה המלא של כתובות ה-URL שהלקוחות ישתמשו בהן כדי לקרוא לשרת ה-API של ה-API:
https://[host]/base_path/conditional_flow_pathהערה: הנתיב הבסיסי חייב להיות ייחודי. לא ניתן לפרוס שני שרתי proxy של API עם אותו נתיב בסיס. אם עורכים שרת proxy של API שנפרס ומגדירים את הנתיב הבסיסי לאותו ערך כמו נתיב הבסיס של שרת proxy אחר של API, Edge מבטל באופן אוטומטי את שרת ה-proxy של ה-API כששומרים אותו. לפני שאפשר לפרוס מחדש את שרת ה-API של ה-API, צריך לערוך את הנתיב הבסיסי כך שיהיה ייחודי.
שימוש בתווים כלליים לחיפוש בנתיבים בסיסיים
יש להשתמש בתו כללי לחיפוש
/*/או יותר בנתיבי הבסיס של שרת ה-proxy ל-API, כדי להגן על שרתי ה-proxy של ה-API בעתיד. לדוגמה, נתיב בסיסי של/team/*/membersמאפשר ללקוחות לקרוא ל-https://[host]/team/blue/membersול-https://[host]/team/green/membersבלי שיהיה צורך ליצור שרתי proxy חדשים ל-API כדי לתמוך בצוותים חדשים. לתשומת ליבך:/**/לא נתמך.תיאור תיאור קצר של שרת ה-proxy. - לוחצים על הבא.
- בדף WSDL, בוחרים את סוג שרת ה-API מסוג REST to SOAP to REST.
תופיע טבלה עם הפעולות ש-Edge "גילה" בקובץ WSDL. אפשר לבחור ולהגדיר אילו פעולות רוצים לשלב בשרת ה-API של שרת ה-proxy. הטבלה מוצגת באיור הבא.
- בעמודה 'סוג יציאה', בוחרים את קבוצת הפעולות שבה רוצים להשתמש. ב-WSDL, רכיבים מסוג סוג היציאה מגדירים את הפעולות שאפשר לקרוא בשירות אינטרנט.
- ניתן לשנות את שיטת ה-HTTP המשויכת לפעולה.
הערה: Edge מבצע את "הניחוש הטוב ביותר" כשהוא קובע את שיטת ה-HTTP שבה צריך להשתמש עבור כל פעולה. בדרך כלל עדיף להשתמש ב-GET כי ניתן לשמור בקשות GET במטמון.
- אפשר לשנות את נתיב ה-API ל-REST של פעולה. הנתיב ישמש כשם המשאב בכתובת ה-URL של שרת ה-API של שרת ה-API.
- לוחצים על שאר האשף כדי להוסיף אבטחה, לבחור מארחים וירטואליים ואת סביבת הפריסה.
- בדף 'יצירה', לוחצים על יצירה ופריסה. Edge יוצרת ופורסת את שרת ה-API החדש על סמך ה-WSDL.
- עוברים לדף הסיכום של שרת ה-API החדש proxy. שימו לב שקבוצת משאבים נוצרה על סמך הפעולות שהתגלו בקובץ ה-WSDL.
בדף Overview (סקירה כללית) של שרת ה-proxy, ברשימה Resources יש תיאור מפורט של ה-API החדש, הפעולות והפרמטרים שלו. הייצוג הזה הוא בעצם תיעוד העזר של ה-API. Edge יוצרת עבורך את התצוגה הזו של מודל ה-API באופן אוטומטי. צריך רק להרחיב משאב כדי לראות את התיאור ואת פרטי הנתיב שלו.
מידע על שרת ה-proxy הסופי
כש-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 של העברה באמצעות האפשרות שרת proxy לאימות בתיבת הדו-שיח 'יצירת שרת Proxy חדש'.
סקירה כללית
בעזרת האפשרות Pass-Through Proxy אפשר ליצור שרת Proxy שמעביר את הודעת ה-SOAP בבקשה לשירות לקצה העורפי 'untouched', וכך קל מאוד ליצור שרת proxy לשירות אינטרנט שמבוסס על SOAP. מאחורי הקלעים, Edge מטפל עבורך באופן אוטומטי בכל הטרנספורמציות ובפעילויות זרימה אחרות. לדוגמה, אם הבקשה היא בפורמט JSON, Edge מבצע את הפעולות הנדרשות כדי להמיר אותה להודעת XML SOAP חוקית עם מרחבי שמות נכונים לפני שליחתה לשירות. באופן דומה, כששירות מחזיר תגובת SOAP המבוססת על XML, Edge מתרגם אותה חזרה ל-JSON לפני החזרתה ללקוח. בנוסף, Edge מגדירה את נקודת הקצה של היעד העורפי, שמשתנה בהתאם לפעולת SOAP.
לסוג שרת ה-Proxy הזה, Edge מארח את ה-WSDL ויוצר זרימה בשרת ה-proxy כדי
לקבל גישה אליו. הכתובת של ה-WSDL הזה שמתארח ב-Edge,
http(s)://[proxy_domain]/[proxy_base_path]?wsdl, הופכת לכתובת ה-URL החדשה של נקודת הקצה של השירות, ללקוחות שקוראים לשירות SOAP דרך שרת ה-proxy.
שלבים בסיסיים
Edge
כדי ליצור שרת proxy של העברה לשירות מבוסס SOAP באמצעות ממשק המשתמש של Edge:
- נכנסים לאתר apigee.com/edge.
- בסרגל הניווט הימני, בוחרים באפשרות פיתוח > שרתי proxy של API.
- לוחצים על +שרת Proxy.
- לוחצים על שירות SOAP.
- בדף הפרטים של שרת ה-proxy, מזינים את פרטי WSDL.
שדה התיאור WSDL בוחרים את המקור של ה-WSDL.
- מכתובת אינטרנט (כתובת URL) – מזינים או מדביקים את כתובת ה-URL של ה-WSDL.
- מהמחשב שלי – מעלים קובץ WSDL מהספרייה המקומית שלכם. אם יש יחסי תלות, אפשר להעלות מספר קבצים.
שם השם של שרת ה-API של שרת ה-API.
נתיב בסיסי קטע ה-URI אחרי הכתובת http(s)://[host] של שרת ה-API של שרת ה-API. Edge משתמש ב-URI של הנתיב הבסיסי כדי להתאים ולנתב הודעות נכנסות של בקשות לשרת ה-API המתאים.
הערה: לקבלת המלצות של Apigee בנושא ניהול גרסאות של API, קראו את המאמר ניהול גרסאות בספר האלקטרוני Web API Design: The missing Link.
אחרי הנתיב הבסיסי מופיעות כתובות URL נוספות של משאבים. זהו המבנה המלא של כתובות ה-URL שבו הלקוחות ישתמשו כדי לקרוא לשרת ה-API של ה-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 כדי לתמוך בצוותים חדשים. לתשומת ליבך, התו /**/ לא נתמך.הערה: נתיב הבסיס של שרת ה-API של ה-API מוגדר כברירת מחדל לערך שצוין בשדה Name (שם) שהומר לאותיות קטנות בלבד, אלא אם עורכים את התוכן באופן מפורש בשדה 'נתיב בסיס'.
התיאור (אופציונלי) תיאור של ה-API. - לוחצים על הבא.
- בדף Common policies (כללי מדיניות נפוצים) באשף, מגדירים את הפריטים הבאים:
- דרישות להרשאות אבטחה. למידע נוסף, ראו הוספת אבטחה.
- תמיכה בשיתוף משאבים בין מקורות (CORS). למידע נוסף, ראו הוספת תמיכה ב-CORS.
- מכסות להגנה על השירות לקצה העורפי מפני תנועת גולשים רבה. מידע נוסף זמין בקטע Quotas. (האפשרות הזו לא זמינה אם נבחרה הרשאת העברה).
- אכיפת הגבלת המונטיזציה בארגונים שאפשר להפעיל בהם מונטיזציה. למידע נוסף, אפשר לקרוא את המאמר אכיפת מגבלות מונטיזציה בשרתי proxy ל-API.
- בדף WSDL, בוחרים את סוג שרת ה-API מסוג Pass-through SOAP.
- בתפריט הנפתח, בוחרים סוג יציאה כדי לציין באיזו קבוצת פעולות רוצים להשתמש. ב-WSDL, רכיבים מסוג סוג היציאה מגדירים את הפעולות שאפשר לקרוא בשירות אינטרנט.
- לוחצים על הבא.
- בדף מארחים וירטואליים באשף, בוחרים את המארחים הווירטואליים ששרת ה-proxy של ה-API יקשר אליהם במהלך הפריסה. למידע נוסף, קראו את המאמר מידע על מארחים וירטואליים.
- בוחרים את סביבות הפריסה ולוחצים על יצירה ופריסה.
שרת ה-API החדש של ה-API נוצר ונפרס בסביבה שנבחרה. - לוחצים על Edit proxy כדי להציג את דף הפרטים של שרת ה-API.
Classic Edge (ענן פרטי)
כדי ליצור שרת proxy של העברה לשירות מבוסס SOAP באמצעות ממשק המשתמש הקלאסי של Edge:
- נכנסים אל
http://ms-ip:9000. ms-ip הוא כתובת ה-IP או שם ה-DNS של הצומת של שרת הניהול. - בסרגל הניווט העליון, בוחרים באפשרות APIs > API Proxies (ממשקי API > ממשקי API).
- לוחצים על + API Proxy.
- באשף Build a Proxy, בוחרים שירות SOAP.
- לוחצים על הבא.
- בדף 'פרטים', בוחרים באפשרויות הבאות. אחרי הבחירה ב-WSDL, צריך ללחוץ על אימות.
בשדה הזה עשה זאת WSDL בוחרים את המקור של ה-WSDL.
- כתובת URL – מזינים את כתובת ה-URL של ה-WSDL שרוצים להשתמש בו.
- קובץ - בוחרים קובץ WSDL במערכת הקבצים שלכם. אם יש קבצים תלויים נוספים, אפשר לבחור את כולם.
- דוגמה לכתובת URL – אפשר לבחור מתוך רשימה של WSDL לשירותי אינטרנט שזמינים לציבור. כדאי לנסות את התכונות של שרת ה-proxy של SOAP/ל-API ב-Edge.
שם שרת Proxy זה השם של שרת ה-proxy שיוצרים.
נתיב בסיס של שרת Proxy נתיב הבסיס של שרת ה-proxy הוא מקטע URI שמזהה באופן ייחודי את ה-API שנחשף על ידי שרת ה-proxy הזה של ה-API. שירותי API משתמשים ב-URI של נתיב הבסיס כדי להתאים ולנתב הודעות נכנסות של בקשות לשרת ה-API המתאים. (נתיב הבסיס מצורף לדומיין של ה-API, שנוצר באופן אוטומטי על סמך שם הארגון והסביבה שבה נפרס שרת ה-proxy של ה-API). מומלץ לכלול מספר גרסה בשם הפרויקט, לדוגמה /v1/delayedstockquote. ההגדרה הזו תקבע איך אפליקציות לצרכנים יופעלו על ידי ה-API שלך.הערה: ערך ברירת המחדל של נתיב הבסיס של שרת ה-Proxy הוא הערך שצוין בשדה 'שם שרת Proxy' שהומר לאותיות קטנות בלבד, אלא אם עורכים באופן מפורש את התוכן בשדה 'נתיב הבסיס של שרת ה-Proxy'.
תיאור תיאור קצר של שרת ה-proxy. - לוחצים על הבא.
- בדף WSDL, בוחרים את סוג שרת ה-API מסוג Pass-through SOAP.
הערה: תוצג טבלה שבה מפורטות כל פעולת WSDL והמטען הייעודי (payload) המתאים של SOAP. זהו המטען הייעודי (payload) ש "מועבר" לשירות SOAP בקצה העורפי.
- בעמודה 'סוג יציאה', בוחרים את קבוצת הפעולות שבה רוצים להשתמש. ב-WSDL, רכיבים מסוג סוג היציאה מגדירים את הפעולות שאפשר לקרוא בשירות אינטרנט.
- לוחצים על שאר האשף כדי להוסיף אבטחה, לבחור מארחים וירטואליים ואת סביבת הפריסה.
- בדף 'יצירה', לוחצים על יצירה ופריסה. Edge יוצרת ופורסת את שרת ה-API החדש על סמך ה-WSDL.
מידע על שרת ה-proxy הסופי
כש-Edge יוצר שרת proxy למעבר, שרת ה-proxy שנוצר הוא למעשה תהליך מורכב שכולל מדיניות לשינוי נתונים, לחילוץ ולהגדרה של משתנים, ביצוע מניפולציות על הודעות ועוד. אחרי שיוצרים את שרת ה-proxy להעברה, אפשר לבדוק את התהליך שמתקבל בתצוגת הפיתוח של ממשק המשתמש לניהול API. שם אפשר לראות בדיוק אילו כללי מדיניות נוספו.
לדוגמה, באיור הבא מוצג החלק של Target Endpoint Preflow מתוך שרת proxy להעברות. בצד הבקשה, נעשה שימוש במדיניות assignMessage כדי להגדיר את כתובת ה-URL של היעד. בצד התגובה, המדיניות מבצעת טרנספורמציה של התגובה מ-XML ל-JSON, מחלצת את החלק של גוף התגובה של SOAP למשתנה ומגדירים את הודעת התגובה. כללי המדיניות האלה (ואחרים) נוספים באופן אוטומטי כשיוצרים את שרת ה-proxy.
WSDL שמתארח ב-Edge: כדי לראות את ה-WSDL המתארח ב-Edge שנוצר עבור סוג
ה-Proxy הזה, יש לעבור אל http(s)://[proxy_domain]/[proxy_base_path]?wsdl.
פיתוח מתקדם של שרת proxy מסוג SOAP ל-REST
בקטעים הקודמים עסקנו ביצירת שרת proxy של SOAP-to-REST באמצעות אשף שרת ה-proxy של API ב-Edge. עם זאת, אם רוצים שליטה מדויקת יותר על הטרנספורמציה SOAP-ל-REST, אפשר לעקוף את האוטומציה שהאשף מספק, ולבנות שרת proxy על ידי הוספה והגדרה ידנית של כללי מדיניות כדי לקבל את ההתנהגות הרצויה. אפשר לקרוא מידע נוסף במדריך: יצירה ידנית של שרת proxy מסוג SOAP-to-REST API ב-Apigee Edge.