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