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

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

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

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

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

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

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

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