שיטות מומלצות לעיצוב ולפיתוח של proxy ל-API באמצעות Apigee

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

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

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

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

תקני פיתוח

תגובות ומסמכי תיעוד

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

כתיבת קוד בסגנון Framework

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

  • כדי להפעיל DRY (אל תחזרו על עצמכם), כדאי להטמיע פונקציות מיוחדות שאפשר להשתמש בהן מחדש בהגדרות המדיניות ובסקריפטים, איפה שאפשר. לדוגמה, מדיניות ייעודית לחילוץ פרמטרים של שאילתה מהודעות בקשה יכולה להיקרא ExtractVariables.ExtractRequestParameters.
  • כדאי לנקות מדיניות ומשאבים שלא נעשה בהם שימוש (JavaScript,‏ Java,‏ XSLT וכו') משרתי proxy של API, במיוחד משאבים גדולים שיכולים להאט את תהליכי הייבוא והפריסה.

מוסכמות למתן שמות

  • המאפיין name של המדיניות ושם קובץ המדיניות ב-XML חייבים להיות זהים.
  • המאפיין name של מדיניות Script ומדיניות ServiceCallout והשם של קובץ המשאב צריכים להיות זהים.
  • DisplayName צריך לתאר באופן מדויק את הפונקציה של המדיניות למי שלא עבד עם proxy ל-API הזה בעבר.
  • נותנים שמות למדיניות בהתאם לפונקציה שלה. מומלץ ב-Apigee לקבוע מוסכמה עקבית למתן שמות למדיניות. לדוגמה, אפשר להשתמש בקידומות קצרות ואחריהן ברצף של מילים תיאוריות שמופרדות באמצעות מקפים. לדוגמה, AM-xxx עבור מדיניות AssignMessage. אפשר לעיין גם במאמר בנושא הכלי apigeelint.
  • צריך להשתמש בסיומות המתאימות לקובצי משאבים, .js ל-JavaScript,‏ .py ל-Python ו.jar לקובצי JAR של Java.
  • שמות המשתנים צריכים להיות עקביים. אם בוחרים סגנון, כמו camelCase או under_score, צריך להשתמש בו בכל ה-proxy ל-API.
  • כדאי להשתמש בקידומות של משתנים, כשזה אפשרי, כדי לארגן את המשתנים לפי המטרה שלהם. לדוגמה, Consumer.username ו-Consumer.password.

פיתוח של proxy ל-API

שיקולים ראשוניים בתכנון

  • כדי לקבל הנחיות לעיצוב API ל-REST, אפשר להוריד את הספר הדיגיטלי Web API Design: The Missing Link.
  • כדי ליצור שרתי proxy ל-API, כדאי להשתמש במדיניות ובפונקציונליות של Apigee ככל האפשר. אל תכתבו את כל הלוגיקה של ה-proxy במשאבי JavaScript,‏ Java או Python.
  • בניית תהליכי עבודה בצורה מאורגנת. עדיף להשתמש בכמה רכיבי Flow, שלכל אחד מהם יש תנאי אחד, במקום בכמה קבצים מצורפים מותנים לאותו רכיב PreFlow ולאותו רכיב Postflow.
  • כדי ליצור 'מנגנון למקרה של כשל', יוצרים שרת proxy ל-API כברירת מחדל עם BasePath של ProxyEndpoint ‏/. אפשר להשתמש בזה כדי להפנות בקשות API בסיסיות לאתר של מפתח, כדי להחזיר תגובה מותאמת אישית או כדי לבצע פעולה אחרת שימושית יותר מאשר החזרת messaging.adaptors.http.flow.ApplicationNotFound שמוגדר כברירת מחדל.
  • כדי להשיג ביצועים אופטימליים, Apigee ממליצה להשתמש בלא יותר מ-3,000 נתיבי בסיס של שרתי proxy ל-API לכל סביבת Apigee או קבוצת סביבות. חריגה מההמלצה הזו עלולה להוביל לזמן אחזור מוגבר בכל הפריסות החדשות והקיימות של proxy ל-API.
  • שימוש במשאבי TargetServer כדי להפריד בין הגדרות TargetEndpoint לבין כתובות URL קונקרטיות, כך שניתן יהיה לקדם את השימוש בהן בסביבות שונות.
    מידע נוסף על איזון עומסים בשרתי בק-אנד
  • אם יש לכם כמה RouteRule, צריך ליצור אחד כ 'ברירת מחדל', כלומר כ-RouteRule ללא תנאי. מוודאים ש-RouteRule שמוגדר כברירת מחדל מוגדר אחרון ברשימת המסלולים המותנים. הערכת הכללים של RouteRules מתבצעת מלמעלה למטה ב-ProxyEndpoint. מידע נוסף זמין במאמר בנושא הפניית הגדרות של שרת proxy ל-API.
  • גודל חבילת ה-proxy ל-API: חבילות ה-proxy ל-API לא יכולות להיות גדולות מ-15MB.
  • ניהול גרסאות API: כדי לקרוא על ההמלצות של Apigee בנושא ניהול גרסאות API, אפשר לעיין במאמר Versioning בספר הדיגיטלי Web API Design: The Missing Link.

הפעלת CORS

לפני שמפרסמים את ממשקי ה-API, צריך להוסיף את מדיניות ה-CORS אל בקשת PreFlow של ProxyEndpoint כדי לתמוך בבקשות חוצות מקור בצד הלקוח.

שיתוף משאבים בין מקורות (CORS) הוא מנגנון סטנדרטי שמאפשר לקריאות JavaScript XMLHttpRequest ‏ (XHR) שמופעלות בדף אינטרנט ליצור אינטראקציה עם משאבים מדומיינים שאינם מקור. CORS הוא פתרון נפוץ למדיניות המקור הזהה שנאכפת על ידי כל הדפדפנים. לדוגמה, אם מבצעים קריאת XHR ל-Twitter API מקוד JavaScript שמופעל בדפדפן, הקריאה תיכשל. הסיבה לכך היא שהדומיין שממנו הדף מוצג בדפדפן שלכם לא זהה לדומיין שממנו מוצג Twitter API. CORS מספק פתרון לבעיה הזו בכך שהוא מאפשר לשרתים להביע הסכמה אם הם רוצים לספק שיתוף משאבים בין מקורות.

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

גודל המטען הייעודי של ההודעה

גודל המטען הייעודי (payload) של ההודעה בתהליכי בקשה או תגובה ב-Apigee מוגבל כברירת מחדל ל-10MB. משתמשים שצריכים לעבד מטען ייעודי (payload) גדול יכולים להגדיר מגבלה גבוהה יותר באמצעות הרכיב <Properties> בהגדרות של ProxyEndpoint או TargetEndpoint של שרתי ה-API שלהם.

מידע נוסף על שימוש במאפיינים response.payload.parse.limit או request.payload.parse.limit כדי להגדיר גודל מטען ייעודי מרבי של עד 30MB לזרימות של בקשות או תגובות זמין במאמר בנושא הפניה להגדרת proxy ל-API.

שימו לב: חריגה מגודל ההודעה שצוין תגרום לשגיאה protocol.http.TooBigBody.

כדאי לשקול את האסטרטגיות המומלצות הבאות לטיפול בגדלים גדולים של הודעות ב-Apigee:

  • מומלץ מאוד לבודד את ה-API proxies שמטפלים לעיתים קרובות במטענים גדולים בסביבה ייעודית כדי להימנע מתרחיש פוטנציאלי של "שכן רועש". פרוקסי שמנהלים מטענים ייעודיים (payload) גדולים צורכים כמויות גדולות יותר של משאבי CPU וזיכרון במערכת, במיוחד כשמשתמשים בהם בשילוב עם כללים שפועלים עם מטענים ייעודיים גדולים.
  • מומלץ גם להגביל את השימוש במדיניות לאינטראקציה עם מטען ייעודי גדול. שימוש במדיניות כדי לנתח ולהעתיק שוב ושוב מטען ייעודי של בקשות או תגובות עלול לפגוע בביצועי המערכת.
  • ארגונים שמטפלים בנפחים גדולים של בקשות עם מטען ייעודי גדול מוזמנים לספק כתובות IP נוספות כדי למנוע את הבעיה של מיצוי יציאות בגלל הרחבה אופקית.
  • מומלץ להשתמש בסטרימינג של בקשות ותשובות. הערה: כשמבצעים סטרימינג, למדיניות כבר אין גישה לתוכן ההודעות. איך שולחים בקשות ומקבלים תשובות בסטרימינג
  • אם הארגון שלכם משתמש בתשלום לפי שימוש, מומלץ להשתמש במגבלות שניתנות להגדרה עבור מטען ייעודי גדול רק עבור שרתי proxy של API שנפרסו בסביבה מקיפה.

טיפול בשגיאות

  • כדאי להשתמש ב-FaultRules כדי לטפל בכל השגיאות. (מדיניות RaiseFault משמשת להפסקת זרימת ההודעות ולהעברת העיבוד לזרימת FaultRules).
  • בתוך רכיב FaultRules Flow, משתמשים במדיניות AssignMessage כדי ליצור את תגובת השגיאה, ולא במדיניות RaiseFault. הפעלה מותנית של מדיניות AssignMessage על סמך סוג השגיאה שמתרחשת.
  • תמיד כולל מטפל ברירת מחדל בשגיאות, כך שאפשר למפות שגיאות שנוצרו על ידי המערכת לפורמטים של תגובות לשגיאות שהוגדרו על ידי הלקוח.
  • אם אפשר, תמיד כדאי לוודא שתגובות השגיאה תואמות לפורמטים סטנדרטיים שזמינים בחברה או בפרויקט.
  • השתמשו בהודעות שגיאה משמעותיות שאנשים יכולים לקרוא, שמציעות פתרון למצב השגיאה.

מידע נוסף על טיפול בתקלות

התמדה

מפות של צמדי מפתח/ערך

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

מדיניות בנושא פעולות ב-KeyValueMap

שמירת תגובות במטמון

  • אל תאכלס את מטמון התגובות אם התגובה לא מוצלחת או אם הבקשה היא לא GET. אין לשמור במטמון פעולות של יצירה, עדכון ומחיקה. <SkipCachePopulation>response.status.code != 200 or request.verb != "GET"</SkipCachePopulation>
  • מאכלסים את המטמון בסוג תוכן עקבי אחד (לדוגמה, XML או JSON). אחרי שמאחזרים רשומה של responseCache, ממירים אותה לסוג התוכן הנדרש באמצעות JSONtoXML או XMLToJSON. כך לא יאוחסנו נתונים כפולים, משולשים או יותר.
  • מוודאים שמפתח המטמון מספיק לדרישת האחסון במטמון. במקרים רבים, אפשר להשתמש ב-request.querystring כמזהה הייחודי.
  • לא לכלול את מפתח ה-API ‏ (client_id) במפתח המטמון, אלא אם נדרש במפורש. ברוב המקרים, ממשקי API שמאובטחים רק באמצעות מפתח יחזירו את אותם נתונים לכל הלקוחות עבור בקשה נתונה. לא יעיל לאחסן את אותו ערך למספר רשומות על סמך מפתח ה-API.
  • כדי להימנע מקריאות לא מדויקות, צריך להגדיר מרווחי זמן מתאימים לתפוגת מטמון.
  • כשאפשר, כדאי שהמדיניות של מטמון התגובות שאחראית לאכלוס המטמון תופעל ב-PostFlow של התגובה ProxyEndpoint כמה שיותר מאוחר. במילים אחרות, צריך להגדיר שהפעולה תתבצע אחרי שלבי התרגום והגישור, כולל גישור מבוסס-JavaScript והמרה בין JSON ל-XML. באמצעות שמירת נתונים בתקשורת בזיכרון מטמון, אתם נמנעים מעלות הביצועים של הפעלת שלב התקשורת בכל פעם שאתם מאחזרים נתונים שנשמרו במטמון.

    שימו לב: אם תהליך בחירת הרשת מניב תגובה שונה מבקשה לבקשה, כדאי לשמור במטמון נתונים שלא עברו תהליך בחירת רשת.

  • מדיניות מטמון התגובות לחיפוש רשומת המטמון צריכה להופיע ב-PreFlow של בקשת ProxyEndpoint. מומלץ להימנע מהטמעה של יותר מדי לוגיקה, מלבד יצירת מפתח מטמון, לפני החזרת רשומה במטמון. אחרת, היתרונות של השמירה במטמון יהיו מינימליים.
  • באופן כללי, תמיד כדאי לבצע את החיפוש במטמון התגובות כמה שיותר קרוב לבקשת הלקוח. לעומת זאת, כדאי לשמור את נתוני המטמון של התגובות כמה שיותר קרוב לתגובת הלקוח.
  • כשמשתמשים בכמה כללי מדיניות שונים של מטמון תגובות בשרת proxy, חשוב לפעול לפי ההנחיות הבאות כדי להבטיח התנהגות נפרדת לכל אחד מהם:
    • מריצים כל מדיניות על סמך תנאים שאינם חופפים. כך תוכלו לוודא שרק אחת מתוך כמה מדיניות של מטמון תגובות תופעל.
    • צריך להגדיר משאבי מטמון שונים לכל מדיניות מטמון תגובות. מציינים את משאב המטמון ברכיב <CacheResource> של המדיניות.

מדיניות ResponseCache

מדיניות וקוד בהתאמה אישית

מדיניות או קוד בהתאמה אישית?

  • קודם כול, מומלץ להשתמש במדיניות מובנית (כשהדבר אפשרי). כללי המדיניות של Apigee מחוזקים, עוברים אופטימיזציה ונתמכים. לדוגמה, במקום להשתמש ב-JavaScript (כשאפשר), כדאי להשתמש במדיניות הרגילה AssignMessage ובמדיניות ExtractVariables כדי ליצור מטען ייעודי (payload), לחלץ מידע ממטען ייעודי (XPath,‏ JSONPath) וכן הלאה.
  • עדיף להשתמש ב-JavaScript במקום ב-Python וב-Java. עם זאת, אם הביצועים הם הדרישה העיקרית, עדיף להשתמש ב-Java ולא ב-JavaScript.

JavaScript

  • כדאי להשתמש ב-JavaScript אם הוא אינטואיטיבי יותר ממדיניות Apigee (לדוגמה, כשמגדירים target.url לשילובים רבים ושונים של URI).
  • ניתוח מטען ייעודי מורכב, כמו איטרציה דרך אובייקט JSON וקידוד/פענוח Base64.
  • מדיניות JavaScript כוללת הגבלת זמן, ולכן לולאות אינסופיות נחסמות.
  • תמיד משתמשים בפעולות JavaScript ומכניסים קבצים לתיקיית המשאבים jsc. סוג המדיניות JavaScript מבצע קומפילציה מראש של הקוד בזמן הפריסה.

Java

  • מומלץ להשתמש ב-Java אם הביצועים הם העדיפות הכי גבוהה, או אם אי אפשר להטמיע את הלוגיקה ב-JavaScript.
  • הכללת קובצי מקור של Java במעקב אחר קוד מקור.

מידע על שימוש ב-Java ב-API proxies זמין במאמר בנושא JavaCallout policy.

Python

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

הסברים טקסטואליים בסקריפט (Java, ‏ JavaScript, ‏ Python)

  • משתמשים ב-try/catch גלובלי או במקבילה.
  • כדאי להשתמש בחריגים משמעותיים ולטפל בהם בצורה נכונה כדי להשתמש בהם בתגובות לשגיאות.
  • הקפצת הודעת שגיאה (throw) וחריגות (catch) בשלב מוקדם. אל תשתמשו ב-try/catch גלובלי כדי לטפל בכל החריגים.
  • מבצעים בדיקות של null ו-undefined, כשצריך. דוגמה למקרה שבו כדאי לעשות את זה היא כשמאחזרים משתני זרימה אופציונליים.
  • מומלץ להימנע משליחת בקשות HTTP/S בתוך קריאה לסקריפט. במקום זאת, אפשר להשתמש במדיניות ServiceCallout, כי היא מטפלת בחיבורים בצורה חלקה.

JavaScript

  • ‫JavaScript בפלטפורמת ה-API תומך ב-XML באמצעות E4X.

מידע נוסף מופיע במאמר בנושא מודל אובייקטים של JavaScript.

Java

  • כשניגשים למטענים ייעודיים (payload) של הודעות, כדאי להשתמש ב-context.getMessage() במקום ב-context.getResponseMessage או ב-context.getRequestMessage. כך מוודאים שהקוד יכול לאחזר את מטען הנתונים, גם בתהליכי בקשה וגם בתהליכי תגובה.
  • מייבאים ספריות לארגון או לסביבה של Apigee ולא כוללים אותן בקובץ ה-JAR. כך מקטינים את גודל החבילה ומאפשרים לקובצי JAR אחרים לגשת לאותו מאגר ספריות.
  • ייבוא קובצי JAR באמצעות Apigee resources API במקום לכלול אותם בתיקיית המשאבים של API proxy. כך מקצרים את זמני הפריסה ומאפשרים לכמה שרתי proxy של API להפנות לאותם קובצי JAR. יתרון נוסף הוא בידוד של טוען המחלקות.
  • אל תשתמשו ב-Java לטיפול במשאבים (לדוגמה, ליצירה ולניהול של מאגרי שרשורים).

Python

  • השלכת חריגים משמעותיים ותפיסה שלהם בצורה נכונה לשימוש בתגובות של Apigee fault

מדיניות PythonScript

ServiceCallouts

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

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

  • יוצרים הודעת בקשה מסוג ServiceCallout באמצעות מדיניות AssignMessage, ומאכלסים את אובייקט הבקשה במשתנה של הודעה. (כולל הגדרת המטען הייעודי (payload), הנתיב והשיטה של הבקשה).
  • כתובת ה-URL שמוגדרת במדיניות מחייבת ציון של הפרוטוקול, כלומר אי אפשר לציין את חלק הפרוטוקול בכתובת ה-URL, https:// למשל, באמצעות משתנה. בנוסף, צריך להשתמש במשתנים נפרדים לחלק הדומיין של כתובת ה-URL ולשאר כתובת ה-URL. לדוגמה: https://example.com.
  • שמירת אובייקט התגובה של ServiceCallout במשתנה הודעה נפרד. לאחר מכן תוכלו לנתח את משתנה ההודעה ולשמור את מטען הנתונים המקורי של ההודעה לשימוש בכללי מדיניות אחרים.

מדיניות בנושא ServiceCallout

גישה לישויות

מדיניות AccessEntity

  • כדי לשפר את הביצועים, כדאי לחפש אפליקציות לפי uuid במקום לפי שם האפליקציה.

מידע על מדיניות AccessEntity

רישום ביומן

  • כדאי להשתמש במדיניות syslog נפוצה בחבילות שונות ובאותה חבילה. כך נשמר פורמט עקבי של רישום ביומן.

מדיניות בנושא רישום הודעות ביומן

מעקב

לקוחות Cloud לא נדרשים לבדוק רכיבים ספציפיים של Apigee (נתבים, מעבדי הודעות וכו'). צוות התפעול הגלובלי של Apigee עוקב בקפידה אחרי כל הרכיבים, וגם אחרי בדיקות תקינות של API, בהתאם לבקשות של הלקוח לבדיקות תקינות.

Apigee Analytics

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

מידע על מרכזי בקרה ב-Analytics

ניפוי באגים

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

איך משתמשים בכלי לניפוי באגים

אבטחה

לוגיקה מותאמת אישית בממשקי proxy ל-API

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

‫Apigee מספק למפתחים כמה אפשרויות להתמודדות עם לוגיקה מותאמת אישית כזו. במסמך הזה נסביר על האפשרויות האלה ומתי כדאי להשתמש בכל אחת מהן:

מדיניות תרחישים לדוגמה לשימוש במדיניות
‫JavaScript ו-PythonScript

מתי כדאי להשתמש במאפיין הזה:

  • היכולות של מדיניות JavaScript זהות לאלה של מדיניות PythonScript. ההיכרות של המפתח עם שפה מסוימת היא בדרך כלל הסיבה לבחירה בה על פני שפה אחרת.
  • מדיניות JavaScript ו-PythonScript מתאימה ביותר לעיבוד לוגיקה מוטמעת שלא מורכבת מדי ולא דורשת שימוש בספריות של צד שלישי.
  • הביצועים של המדיניות הזו לא טובים כמו הביצועים של מדיניות JavaCallout.

מתי לא מומלץ להשתמש במודעות מהסוג הזה:

  • שער ה-API של Apigee הוא לא שרת אפליקציות (וגם לא מספק את זמן הריצה המלא של JavaScript כמו node.js). אם העיבוד של ה-callout תמיד נמשך יותר משנייה, סביר להניח שהלוגיקה לא שייכת לשער וצריכה להיות חלק מהשירות הבסיסי.

שיטה מומלצת: ב-Apigee מומלץ להשתמש ב-JavaScript במקום ב-PythonScript, כי הביצועים של JavaScript טובים יותר.
JavaCallout

מתי כדאי להשתמש במאפיין הזה:

  • חשוב מאוד לבדוק את הביצועים של עיבוד הלוגיקה בשורה.
  • רוב הלוגיקה מסופקת על ידי ספריות Java קיימות.

מתי לא מומלץ להשתמש במודעות מהסוג הזה:

  • שער ה-API של Apigee הוא לא שרת אפליקציות, והוא לא מיועד לטעינת מסגרות כמו Spring, ‏ JEE וכו'. אם בדרך כלל לוקח יותר משנייה לעבד את ה-callout, אפשר להגדיר את הלוגיקה כפונקציונלית (לוגיקה עסקית). כדאי לשקול להשתמש בשירות חיצוני.
  • כדי להגן על שער ה-API של Apigee מפני שימוש לרעה, יש הגבלות על סוג הקוד שאפשר להריץ. לדוגמה, קוד Java שמנסה לגשת לספריות קריפטו מסוימות או לגשת למערכת הקבצים נחסם מהרצה.
  • אפליקציות Java, במיוחד כאלה שמסתמכות על ספריות של צד שלישי, יכולות להכיל הרבה קובצי JAR (גדולים). הפעולות האלה עלולות להאט את זמן האתחול של השערים.
ExternalCallout

מתי כדאי להשתמש במאפיין הזה:

  • האפשרות הזו מתאימה במיוחד להוצאת לוגיקה מותאמת אישית ולאפשר ללוגיקה המותאמת אישית לגשת להקשר של ההודעה (ולשנות אותו אם צריך).
  • התכונה External callouts (קריאות חיצוניות) מבוססת על gRPC, והביצועים שלה עשויים להיות טובים יותר מאלה של ServiceCallout.
  • כשמשתמשים ב-Apigee או ב-Apigee Hybrid ב-Google Cloud, כדאי להשתמש ב-Cloud Functions או ב-Cloud Run כדי לארח את הלוגיקה הזו.
  • כחלופה יעילה לתכונה Hosted Targets ב-Apigee Edge.

מתי לא מומלץ להשתמש בהן:

  • ללוגיקה פשוטה שאפשר להריץ במהירות, בשורה.
ServiceCallout

מתי כדאי להשתמש במאפיין הזה:

  • הכי טוב להטמיע לוגיקה מורכבת מחוץ לשער. ללוגיקה הזו יכול להיות מחזור חיים משלה (גרסאות ומהדורות), והיא לא משפיעה על הפעולה של שער הכניסה.
  • אם נקודת הקצה של REST/SOAP/GraphQL כבר קיימת או שאפשר להטמיע אותה בקלות
  • כשמשתמשים ב-Apigee או ב-Apigee Hybrid ב-Google Cloud, כדאי להשתמש ב-Cloud Functions או ב-Cloud Run כדי לארח את הלוגיקה הזו.
  • כחלופה יעילה לתכונה Hosted Targets ב-Apigee Edge.

מתי לא מומלץ להשתמש בהן:

  • ללוגיקה פשוטה שאפשר להריץ במהירות, בשורה
  • proxy ל-API צריך להעביר הקשר (כמו משתנים) או לקבל הקשר מההטמעה החיצונית

לסיכום:

  1. אם הלוגיקה פשוטה או טריוויאלית, כדאי להשתמש ב-JavaScript (עדיף) או ב-PythonScript.
  2. אם הלוגיקה של inline דורשת ביצועים טובים יותר מ-JavaScript או מ-PythonScript, צריך להשתמש ב-JavaCallout.
  3. אם הלוגיקה צריכה להיות חיצונית, צריך להשתמש ב-ExternalCallout.
  4. אם כבר יש לכם הטמעות חיצוניות או שהמפתחים מכירים את REST, כדאי להשתמש ב-ServiceCallout.

האיור הבא ממחיש את התהליך הזה: