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

אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info

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

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

המסמכים של ממשקי ה-API של API Services מפורטים במסמך API Reference. תחילת העבודה עם הפניית API

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

סביבה

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

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

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

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

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

משאבי סביבה

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

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

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

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

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