אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע
בנושא הזה מפורטות כמה מאפיינים בסיסיים של שרתי proxy ל-API, וגם קישורים למידע נוסף.
ממשקי API הם נקודות כניסה לאפליקציה אחת כדי להשתמש ביכולות של אפליקציה אחרת. הטמעה של שרתי proxy ל-API כדי ליצור ממשקי API
ב-Apigee Edge, מטמיעים proxy ל-API על ידי הגדרת לוגיקה של proxy ל-API כרצף של שלבים שמופעלים בתגובה לבקשה מקוד הלקוח. אתם חושפים proxy ל-API ללקוחות על ידי הגדרת נקודות קצה שכוללות כתובת URL עם נתיבי משאבים, פועל HTTP, דרישות לגבי תוכן הבקשה וכן הלאה.
למרות שזה נקרא proxy ל-API, מנקודת המבט של קוד הלקוח, זה ה-API.
סקירה כללית של שרתי proxy ל-API זמינה במאמר הסבר על ממשקי API ושרתי proxy ל-API.
אתם מסדרים את רצף הלוגיקה של proxy ל-API באמצעות Flows
בכל אפליקציה, הנתונים זורמים דרך האפליקציה בהתאם ללוגיקה של התנאים. ב-Apigee Edge, נתיב העיבוד מורכב מ-Flows. תהליך הוא רצף של שלבים שמרכיבים את נתיב העיבוד של שרת proxy של API. Flows הם הדרך שבה Apigee Edge מספק מקומות להחלת לוגיקה והתנהגות במקומות ספציפיים מלקוח למשאב קצה עורפי, ואז חזרה ללקוח.
מידע נוסף על תהליכים מופיע במאמר שליטה באופן ההפעלה של שרת proxy באמצעות תהליכים
אתם ניגשים לנתוני מצב באמצעות משתני זרימה שנוצרו על ידי שרתי proxy של API
לפרוקסי של API יש גישה למשתנים שמייצגים את מצב הביצוע. אפשר לגשת למשתנים האלה מ-XML שמגדיר את שרתי ה-proxy של ה-API ואת המדיניות. אפשר גם לגשת אליהם כשמרחיבים proxy ל-API באמצעות שפה פרוצדורלית, כמו Java, JavaScript או Python.
המשתנים האלה נשמרים ב-Apigee Edge. חלק מהמשתנים האלה קיימים כברירת מחדל, בדרך כלל כי הם נפוצים בפעולות של שרתי proxy של API (למשל, כי הם חלק מבקשת HTTP). אפשר גם ליצור משתנים משלכם כדי לעמוד בדרישה לוגית.
מידע נוסף על משתנים זמין במאמר ניהול מצב ה-proxy באמצעות משתני זרימה.
אפשר להגדיר שפרוקסי של API יפעל בתנאים מסוימים
בדומה לרוב שפות התכנות, ב-API Proxy אפשר להגדיר שהקוד יפעל בתנאי מסוים. התנאים מבוססים בדרך כלל על מצב proxy ל-API, שאפשר לגשת אליו באמצעות משתני זרימה. לדוגמה, אפשר להגדיר תנאי שבודק את סוכן המשתמש, ואז מעבד את הבקשה בהתאם.
מידע נוסף על ביצוע מותנה זמין במאמר משתני תהליך ותנאים.
רוב הלוגיקה מיושמת ב-API proxy באמצעות מדיניות
רוב הלוגיקה שמוסיפים ל-proxy ל-API נארזת כמדיניות. מדיניות היא רכיב של Apigee Edge שמכיל לוגיקה של תחום פונקציונלי, כמו אבטחה או ניהול תנועה. אתם מגדירים מדיניות עם XML שקובעת מאפיינים ללוגיקה הבסיסית. אתם מסדרים את כללי המדיניות ברצף של 'שלבים' בתהליך, כך ש-proxy ל-API יבצע את הלוגיקה בסדר הטוב ביותר להשגת היעדים של ה-proxy.
מידע נוסף על כללי מדיניות זמין במאמר מהי מדיניות?
אפשר לכלול קבוצות של פונקציות שאפשר להשתמש בהן שוב
אם proxy ל-API כולל לוגיקה שתשמש מכמה מקומות בקוד – כמו proxy ל-API אחרים – אפשר לאסוף את הלוגיקה הזו לקריאות מכמה מקומות. לדוגמה, אפשר לקבץ לוגיקת אבטחה בזרימה משותפת ששרתי proxy אחרים ל-API קוראים לה, וכך לצמצם את הכפילות בשרתי proxy ל-API.
מידע נוסף על רצפי פעולה משותפים זמין במאמר רצפי פעולה משותפים לשימוש חוזר. מידע נוסף על שרשור של proxy ל-API זמין במאמר שרשור של proxy ל-API.
אפשר לבצע ניפוי באגים בשרת proxy באמצעות הכלי Trace
Apigee Edge כולל כלי Trace שבו אפשר להשתמש כדי לבדוק את זרימת הביצוע של שרת ה-API הפרוקסי כשמבצעים ניפוי באגים ובדיקות. הכלי מציג באופן חזותי כל שלב של proxy ל-API שמופעל עבור בקשה. בדומה למאגר באגים, בכל שלב אפשר לראות את רשימת ערכי המשתנים שמרכיבים את מצב ה-API proxy.
מידע נוסף על ניפוי באגים באמצעות Trace זמין במאמר שימוש בכלי Trace.
שגיאות ב-proxy ל-API מטופלות כבעיות
אם מגדירים handler לשגיאות, אפשר להתאים אישית את השגיאה שמוחזרת ללקוח API. בעזרת רכיבי הטיפול בשגיאות אתם יכולים לשלוט בהודעות השגיאה, בין אם השגיאה נובעת מהקוד שלכם או מרכיב כלול (כמו מדיניות).
מידע נוסף זמין במאמר בנושא טיפול בשגיאות.