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

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X.
מידע

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

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

ממשקי API לשירותי API מתועדים בחומר העזר בנושא API. למידע נוסף, ראו תחילת השימוש בהפניות API.

בסרטון הבא מוצג מבוא לסביבות API ולמחזור החיים של פיתוח API.

סביבה

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

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

תעבורה נכנסת, TLS/SSL של השרת מופעל באופן אוטומטי עבור כל סביבה. שני מארחים וירטואליים מוגדרים מראש בכל סביבה: default ו-secure. ברירת המחדל מגדירה כתובת HTTP, בעוד שבאבטחה מוגדרת כתובת HTTP/S עם TLS/SSL מוגדרים מראש בצד השרת. בהגדרת שרת proxy ל-API, אתם מציינים לאילו מארחים וירטואליים צריך להאזין ל-ProxyEndpoint. כשמקדמים לסביבת ייצור, בדרך כלל משביתים את HTTP על ידי הסרת ה-VirtualHost default מהתצורה של שרת ה-proxy של ה-API.

לדוגמה, שרת ProxyEndpoint הבא מאזין ב-HTTP וב-HTTPS.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

מחיקת ה-VirtualHost default מהתצורה של ProxyEndpoint מאפשרת ליצור שרת proxy של API שמאזין רק ל-HTTPS, ולא ל-HTTP.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

כדי לראות אילו מארחים וירטואליים זמינים בסביבה, בוחרים באפשרות Environments (סביבות) בתפריט הראשי של ממשק המשתמש לניהול.

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

פריסת שרתי proxy של API לסביבות

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

מידע נוסף זמין במאמר הסבר על הפריסה.

פיתוח חוזר בבדיקות

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

קידום מכירות לייצור

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

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

פריסת סקריפטים

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

משאבי סביבה

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

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

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

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

אפשר לקרוא מידע נוסף במאמר הסבר על הפריסה.