בדף הזה מפורטות המלצות למוסכמות למתן שמות לפרויקטים בענן, שאולי תצטרכו ליצור בנוסף לפרויקט בענן עבור קצה העורפי של סביבת הייצור שלכם.
בהתאם למטרה של הסביבה או לשלב במחזור החיים של ה-API, יכול להיות שתרצו:
- משנים את שם ה-API או את שם השירות של Cloud Endpoints. מידע נוסף זמין במאמר בנושא הגדרת נקודות קצה.
- ליצור פרויקט אחר.
- משנים את הנתיב שממנו ה-API מוגש.
הנה כמה תבניות נפוצות שכדאי להשתמש בהן:
ניהול גרסאות של ה-API: אם אתם חושבים שאולי תצטרכו לבצע בעתיד שינויים שלא תהיה תאימות לאחור שלהם, כדאי לתכנן מראש ולהוסיף את מספר הגרסה לנתיב שממנו ה-API מוגש. לדוגמה:
my-api.endpoints.my‐project.cloud.goog/v1/echo
מופעי פיתוח/בדיקה: כל מפתח מפעיל גרסה משלו של השירות, בפרויקט משלו. לדוגמה, דן המפתח משתמש ב:
my-api.endpoints.dan-dev-project.cloud.goog/v1/echo
סביבת ביניים: לפני שפורסים בסביבת הייצור, בודקים את ממשקי ה-API בשרת העורפי של סביבת הביניים, שנמצא בפרויקט משלו. לדוגמה:
my-api.endpoints.my‐project-staging.cloud.goog/v1/echo
הפעלת אלפא פרטית: אם רוצים לבדוק גרסה חדשה של השירות עם חלק מהלקוחות, אבל לא עם כולם, הגישה הכי פשוטה היא להציב את גרסת האלפא בפרויקט משלה, שמספק את רמת הבידוד הגבוהה ביותר מסביבת הייצור. לדוגמה:
my-api.endpoints.my‐project-alpha.cloud.goog/v2alpha/echo
אפשר גם להוסיף את גרסת האלפא לאותו פרויקט, אבל להגדיר אותה כשירות נפרד. מכיוון שזהו שירות נפרד, אתם יכולים להגביל את הגישה רק ללקוחות אלפא. לדוגמה:
my-api-alpha.endpoints.my-project.cloud.goog/v2alpha/echo
הפעלת אלפא פתוחה: אם רוצים להפיץ גרסת אלפא שזמינה לכל הלקוחות, אפשר להוסיף אותה לאותו שירות ולאותו פרויקט של הגרסה הקיימת, ולשנות את הנתיב. לדוגמה:
my-api.endpoints.my-project.cloud.goog/v2alpha/echo