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

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

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

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

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

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

סביבה

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

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

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

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

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

מחיקה של default VirtualHost מההגדרה של ProxyEndpoint יוצרת proxy ל-API שמקשיב רק ל-HTTPS ולא ל-HTTP.

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

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

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

משאבי סביבה

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

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

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

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

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