נקודות עיקריות בפיתוח של שרת proxy ל-API

אתה צופה בתיעוד של Apigee Edge.
הצג תיעוד של Apigee X.

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

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

ב-Apigee Edge, אתם מטמיעים שרתי proxy של API על ידי הגדרת לוגיקת שרת ה-API של ה-API כרצף של צעדים שמבצעים בתגובה לבקשה מקוד לקוח. כדי לחשוף את שרת ה-API ללקוחות, צריך להגדיר נקודות קצה (endpoint) שכוללות כתובת URL עם נתיבי משאבים, פועל HTTP, דרישות גוף וכו'.

הוא נקרא שרת Proxy של API, אבל מנקודת המבט של קוד הלקוח, זה ה-API.

סקירה כללית על ממשקי API ושרתי API

ארגון הרצף של הלוגיקה של שרת ה-API של ה-API באמצעות זרימות

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

מידע נוסף על תהליכי עבודה זמין במאמר שליטה באופן הפעולה של שרת proxy עם זרימות.

אפשר לגשת לנתוני מצב דרך משתני זרימה שנוצרו על ידי שרתי proxy של API

לשרת proxy של API יש גישה למשתנים שמייצגים מצב ביצוע. אפשר לגשת למשתנים האלה מתוך ה-XML שמגדיר את שרתי ה-proxy והמדיניות. אפשר גם לגשת אליהן כשמרחיבים שרת proxy באמצעות שפה פרוצדורלית, כמו Java , JavaScript או Python.

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

מידע נוסף על משתנים זמין במאמר ניהול של מצב שרת proxy עם משתני זרימה.

אפשר להפעיל שרתי proxy של API על תנאי

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

למידע נוסף על הפעלה מותנית, אפשר לעיין במאמר משתני זרימה ותנאים.

הטמעת רוב הלוגיקה בשרת proxy באמצעות API באמצעות כללי מדיניות

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

מידע נוסף על המדיניות זמין במאמר מהי המדיניות?

אפשר לכלול קבוצות לשימוש חוזר

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

מידע נוסף על תהליכים משותפים זמין במאמר שימוש חוזר בתהליכי שיתוף משותפים. מידע נוסף על שרשור של שרתי proxy של API זמין במאמר Chaining API proxys.

אפשר לנפות באגים בשרת proxy באמצעות הכלי למעקב

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

למידע נוסף על ניפוי באגים באמצעות 'מעקב', ראו שימוש בכלי המעקב.

אם אתם מטפלים בשגיאות דרך שרת ה-API כשגיאות

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

מידע נוסף מופיע בקטע טיפול בשגיאות.