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

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

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

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

נכנס, TLS/SSL מופעל באופן אוטומטי עבור כל סביבה. שני מארחים וירטואליים מוגדר מראש בכל סביבה: default ו-secure. ברירת המחדל מגדירה HTTP, ואילו האבטחה מגדירה כתובת HTTP/S עם TLS/SSL בצד השרת שהוגדרו מראש. לחשבון הגדרת שרת Proxy ל-API – אתם מציינים לאילו VirtualHosts ה-ProxyEndpoint צריך להאזין. בקידום ב-prod, בדרך כלל משביתים את HTTP על ידי הסרת default VirtualHost מתצורת שרת ה-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>

כדי לראות אילו VirtualHosts זמינים בסביבה, לחץ על סביבות בתפריט הראשי של ממשק הניהול.

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

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

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

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

התפתחות איטרטיבית בבדיקה

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

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

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

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

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

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

משאבי סביבה

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

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

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

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

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