מחזור החיים של פיתוח 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 שעובדים עליהם בסביבת בדיקה לבין שרתי ה-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 בארכיטקטורת REST שמאפשר לכם לשלב Deployment (פריסה) וניהול של proxy ל-API במחזור החיים של פיתוח התוכנה (SDLC) בארגון שלכם. לדוגמה, כדי לוודא שדרישות האבטחה, המהימנות והעקביות מתקיימות, שימוש נפוץ ב-Apigee API הוא כתיבת סקריפטים או קוד שמבצעים פריסה פרוגרמטית של פרוקסי ל-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 בשרת העורפי. מידע נוסף זמין במאמר תנאים עם משתני זרימה.