מחזור החיים של פיתוח API

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

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

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

פיתוח של ממשקי proxy ל-API

‫Apigee תומך באפשרויות הבאות לפיתוח איטרטיבי של שרתי proxy של API:

מידע נוסף על שרתי proxy ל-API זמין במאמר הסבר על ממשקי API ושרתי proxy ל-API.

פיתוח בענן באמצעות Apigee

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

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

כדי להתחיל לפתח שרתי proxy ל-API באמצעות Apigee, אפשר לעיין במאמר יצירת שרת proxy פשוט ל-API.

פיתוח מקומי באמצעות Apigee ב-VS Code

אתם יכולים להשתמש ב-Apigee ב-Visual Studio Code (VS Code) כדי לפתח את שרתי ה-proxy של ה-API ולאמת את הפונקציונליות באמצעות בדיקות יחידה ובדיקות ידניות (לדוגמה, שליחת בקשה והצגת התוצאות).

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

כדי להתחיל לפתח באופן מקומי את ה-proxy ל-API באמצעות Apigee ב-VS Code, אפשר לעיין במאמר יצירת ה-proxy ל-API הראשון באמצעות Apigee ב-VS Code.

פריסת ממשקי proxy ל-API

יוצרים סביבות שבהן אפשר לפרוס שרתי proxy ל-API. ההבחנה בין סביבות שונות היא שרירותית – כל סביבה מזוהה פשוט על ידי קבוצה שונה של כתובות רשת (כתובות URL). המטרה היא לספק לכם דומיין שבו תוכלו ליצור ולאמת שרתי proxy ל-API לפני שה-API ייחשף למפתחים חיצוניים. מידע נוסף זמין במאמר מידע על סביבות וקבוצות סביבות.

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

‫Apigee תומך בסוגי הפריסה הבאים בסביבה:

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

הוספת כללי מדיניות

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

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

קידום לסביבת הייצור

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

פריסת סקריפטים באמצעות Apigee API

‫Apigee מספק API מסוג RESTful שמאפשר לכם לשלב פריסה וניהול של שרתי proxy ל-API במחזור החיים של פיתוח התוכנה (SDLC) של הארגון. לדוגמה, כדי לוודא שדרישות האבטחה, המהימנות והעקביות מתקיימות, שימוש נפוץ ב-Apigee API הוא כתיבת סקריפטים או קוד שפורסים באופן פרוגרמטי שרתי proxy ל-API ומקדמים אותם מסביבה אחת לסביבה אחרת, כחלק מתהליך אוטומטי גדול יותר.

מידע נוסף זמין במאמר בנושא Apigee API.

ניהול משאבים בסביבה

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

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

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

  • מיפויים של מפתח וערך (KVM): אם המיפויים מוגבלים לסביבה, צריך לוודא שמשתמשים במוסכמות למתן שמות כדי לאפשר לשרתי proxy של API לאחסן נתונים בלי שיהיה צורך לבצע שינויים בהגדרות במהלך הקידום. מידע נוסף זמין במאמר בנושא שימוש במיפויים של מפתח וערך.
  • כתובות URL לטירגוט: בדרך כלל, פרוקסי של API קורא לכתובות URL שונות של קצה עורפי במהלך הבדיקה והייצור. אפשר להשתמש בהגדרות של TargetServer כדי ליצור הגדרות של TargetEndpoint שלא תלויות בסביבה. למידע נוסף, ראו
  • יעדים של ServiceCallout: יכול להיות ש-ServiceCallout ישתמש ביעדים שונים בהתאם לסביבה. לדוגמה, אם ServiceCallout בסביבת הבדיקה צורך שירות הדגמה. מדיניות בנושא ServiceCallout

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