פריסת שרתי proxy של API באמצעות ה-API

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

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

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

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

המידע המלא זמין במאמר ממשקי API של Edge.

כדי להשתמש ב-Edge API, אתם צריכים לאמת את עצמכם בקריאות. אפשר לעשות זאת באחת מהשיטות הבאות:

  • OAuth2 (ענן ציבורי בלבד)
  • SAML (ענן ציבורי ופרטי)
  • Basic Auth (לא מומלץ, ענן ציבורי ופרטי)

הנושא הזה מתמקד בקבוצת ממשקי API שמיועדים לניהול שרתי proxy של API.

סרטון: בסרטון הקצר הזה מוסבר איך לפרוס API.

אינטראקציה עם ה-API

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

הצגה של רשימת ממשקי ה-API בארגון

כדי להתחיל, צריך לפרט את כל שרתי ה-proxy של ה-API בארגון. (חשוב לזכור להחליף את הרשומות של EMAIL:PASSWORD ו-ORG_NAME. להוראות, תוכלו לקרוא את המאמר שימוש ב-Edge API.

curl -u EMAIL:PASSWORD \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis

תשובה לדוגמה:

[ "weatherapi" ]

קבלת API

אפשר להפעיל את method GET בכל שרת proxy של API בארגון. הקריאה הזו מחזירה רשימה של כל הגרסאות הזמינות של שרת ה-API של ה-API.

curl -u EMAIL:PASSWORD -H "Accept: application/json" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi

תשובה לדוגמה:

{
  "name" : "weatherapi",
  "revision" : [ "1" ]
}

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

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

קבלת גרסה ל-API

גרסת ה-API (לדוגמה, api.company.com/v1) אמורה להשתנות לעתים רחוקות מאוד. כשמגדילים את גרסת ה-API, המפתחים רואים שינוי משמעותי בחתימה של הממשק החיצוני שנחשף על ידי ה-API.

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

למשל, אפשר להפעיל את השיטה GET בגרסה 1 של שרת proxy ל-API כדי לקבל תצוגה מפורטת.

curl -u EMAIL:PASSWORD -H "Accept:application/json" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi/revisions/1

תשובה לדוגמה

{
  "configurationVersion" : {
    "majorVersion" : 4,
    "minorVersion" : 0
  },
  "contextInfo" : "Revision 1 of application weatherapi, in organization {org_name}",
  "createdAt" : 1343178905169,
  "createdBy" : "andrew@apigee.com",
  "lastModifiedAt" : 1343178905169,
  "lastModifiedBy" : "andrew@apigee.com",
  "name" : "weatherapi",
  "policies" : [ ],
  "proxyEndpoints" : [ ],
  "resources" : [ ],
  "revision" : "1",
  "targetEndpoints" : [ ],
  "targetServers" : [ ],
  "type" : "Application"
}

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

פריסת API בסביבה

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

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

איך מציינים סביבות

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

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

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

הצגה של הסביבות בארגון

curl -u EMAIL:PASSWORD \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments

תשובה לדוגמה

[ "test", "prod" ]

עיון בפריסות

פריסה היא גרסה של שרת proxy של API שנפרס בסביבה. אפשר לגשת לשרת proxy של API שנמצא במצב פריסה דרך הרשת, בכתובות שמוגדרות ברכיב <VirtualHost> של הסביבה הזו.

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

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

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

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

קודם צריך לבטל את הפריסה של הגרסה הקיימת. מציינים את שם הסביבה ואת מספר הגרסה של שרת ה-API שרוצים לבטל את הפריסה שלו:

curl -X DELETE \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments \
  -u EMAIL:PASSWORD

לאחר מכן לפרוס את הגרסה החדשה. הגרסה החדשה של proxy ל-API חייבת כבר להיות קיימת: 

curl -X POST -H "Content-type:application/x-www-form-urlencoded" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments \
  -u EMAIL:PASSWORD

פריסה חלקה (אפס זמן השבתה)

כדי לצמצם את הפוטנציאל לזמן השבתה במהלך הפריסה, צריך להשתמש בפרמטר override בשיטת הפריסה ולהגדיר אותו לערך true.

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

בדוגמה הבאה מגדירים את הערך override על ידי העברתו כפרמטר של טופס: 

curl -X POST -H "Content-type:application/x-www-form-urlencoded" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/e/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments" \
  -d "override=true" \
  -u EMAIL:PASSWORD

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

  • גרסה 1 מטפלת בבקשות.
  • גרסה 2 נפרסת במקביל.
  • כשגרסה 2 נפרסת במלואה, תעבורת נתונים חדשה נשלחת לגרסה 2. לא תישלח תנועה חדשה לגרסה 1.
  • עם זאת, ייתכן שגרסה 1 עדיין מעבדת עסקאות קיימות. כשמגדירים את הפרמטר delay (לדוגמה, 15 שניות), נותנים לגרסה 1 15 שניות לסיום העיבוד של עסקאות קיימות.
  • אחרי מרווח ההשהיה, גרסה 1 לא פורסת.
curl -X POST -H "Content-type:application/x-www-form-urlencoded" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/e/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments?delay=15" \
  -d "override=true" \
  -u EMAIL:PASSWORD
פרמטר שאילתה התיאור
override

ברירת המחדל היא false (התנהגות פריסה רגילה: הגרסה הקיימת לא נפרסה, ואז נפרסת גרסה חדשה).

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

כדי לאפשר את השלמת עיבוד הטרנזקציות לגרסה הקיימת לפני הפריסה שלה — ולבטל את האפשרות ל-502 Bad Gateway או 504 Gateway Timeout errors — יש להגדיר את הפרמטר הזה למספר השניות שבהן ברצונך שהפריסה תתעכב. אין הגבלה על מספר השניות שניתן להגדיר, ואין השלכות על הביצועים של הגדרת מספר גדול של שניות. במהלך העיכוב, לא תישלח תנועה חדשה לגרסה הישנה.

ברירת המחדל היא 0 (אפס) שניות. כאשר override מוגדר כ-True ו-delay הוא 0, הגרסה הקיימת לא נפרסת מיד לאחר הפריסה של הגרסה החדשה. המערכת מתייחסת לערכים שליליים כ-0 (אפס) שניות.

כשמשתמשים ב-override=true יחד עם delay, אפשר לבטל את התגובות של HTTP 5XX במהלך הפריסה. הסיבה לכך היא ששתי הגרסאות של שרת proxy ל-API ייפרסו בו-זמנית, והגרסאות הישנות יותר לא תפרס לאחר העיכוב.

הצגת כל הפריסות של גרסה קודמת של API

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

curl https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi/revisions/1/deployments \
  -u EMAIL:PASSWORD
{
  "aPIProxy" : "weatherapi",
  "environment" : [ {
    "configuration" : {
      "basePath" : "",
      "steps" : [ ]
    },
    "name" : "test",
    "server" : [ {
      "status" : "deployed",
      "type" : [ "message-processor" ],
      "uUID" : "90096dd1-1019-406b-9f42-fbb80cd01200"
    }, {
      "status" : "deployed",
      "type" : [ "message-processor" ],
      "uUID" : "7d6e2eb1-581a-4db0-8045-20d9c3306549"
    }, {
      "status" : "deployed",
      "type" : [ "router" ],
      "uUID" : "1619e2d7-c822-45e0-9f97-63882fb6a805"
    }, {
      "status" : "deployed",
      "type" : [ "router" ],
      "uUID" : "8a5f3d5f-46f8-4e99-b4cc-955875c8a8c8"
    } ],
    "state" : "deployed"
  } ],
  "name" : "1",
  "organization" : "org_name"
}

התגובה שלמעלה מכילה מאפיינים רבים שספציפיים לתשתית הפנימית של Apigee Edge. אין לך אפשרות לשנות את ההגדרות האלה בלי להשתמש ב-Apigee Edge מקומי.

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

הצגת כל הפריסות בסביבת הבדיקה

אפשר גם לאחזר את סטטוס הפריסה של סביבה ספציפית (כולל מספר הגרסה של שרת proxy ל-API שנפרס כרגע) באמצעות הקריאה הבאה:

curl -u EMAIL:PASSWORD
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/test/deployments

הפעולה הזו מחזירה את אותה תוצאה עבור כל API שנפרס בסביבת הבדיקה

הצגת כל הפריסות בארגון

כדי לאחזר רשימה של כל הגרסאות הקודמות שנפרסו בכל שרתי ה-API של ה-API בכל הסביבות, צריך להשתמש בשיטת ה-API הבאה:

curl https://api.enterprise.apigee.com/v1/o/ORG_NAME/deployments \
  -u EMAIL:PASSWORD

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

מכיוון שה-API הוא RESTful, אפשר פשוט להשתמש ב-method POST, ביחד עם מטען ייעודי (payload) של JSON או XML, מול אותו משאב כדי ליצור שרת proxy ל-API.

נוצר פרופיל לשרת ה-API של ה-API. ייצוג ברירת המחדל של שרת proxy ל-API מופיע בסימון אובייקטים של JavaScript (JSON). בהמשך מופיעה תגובת ברירת המחדל מסוג JSON לבקשת POST שלמעלה, שיצרה שרת proxy של API שנקרא weatherapi. תיאור של כל רכיב בפרופיל:

{
  "configurationVersion" : {
    "majorVersion" : 4,
    "minorVersion" : 0
  },
  "contextInfo" : "Revision 1 of application weatherapi, in organization {org_name}",
  "createdAt" : 1357172145444,
  "createdBy" : "you@yourcompany.com",
  "displayName" : "weatherapi",
  "lastModifiedAt" : 1357172145444,
  "lastModifiedBy" : "you@yourcompany.com",
  "name" : "weatherapi",
  "policies" : [ ],
  "proxyEndpoints" : [ ],
  "resources" : [ ],
  "revision" : "1",
  "targetEndpoints" : [ ],
  "targetServers" : [ ],
  "type" : "Application"
}

פרופיל ה-API שנוצר על ידי שרת ה-API מדגים את המבנה המלא של שרת proxy ל-API:

  • APIProxy revision: איטרציה ממוספרת ברצף של תצורת שרת ה-proxy של ה-API, כפי שמתוחזקת על ידי שירותי API
  • APIProxy name: השם הייחודי של שרת ה-API של שרת proxy
  • ConfigurationVersion: גרסת שירותי API שאליה תואם תצורת שרת ה-proxy של ה-API
  • CreatedAt: השעה שבה נוצר שרת ה-proxy של ה-API, בפורמט זמן UNIX
  • CreatedBy: כתובת האימייל של משתמש Apigee Edge שיצר את שרת ה-API
  • DisplayName: שם ידידותי למשתמש לשרת ה-API של שרת ה-proxy
  • LastModifiedAt: השעה שבה נוצר שרת ה-proxy של ה-API, בפורמט בזמן UNIX
  • LastModifiedBy: כתובת האימייל של משתמש Apigee Edge שיצר את שרת ה-API
  • Policies: רשימה של כללי מדיניות שנוספו לשרת proxy זה ל-API
  • ProxyEndpoints: רשימה של ProxyEndpoints
  • Resources: רשימת משאבים (JavaScript, Python, Java, XSLT) הזמינים להפעלה בשרת ה-proxy הזה של ה-API
  • TargetServers: רשימה של TargetServers בשם (שניתן ליצור באמצעות ה-Management API), שמשמשים בהגדרות מתקדמות למטרות איזון עומסים
  • TargetEndpoints: רשימה של TargetEndpoints

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

אפשר גם לקרוא על רכיבי התצורה האלה בחומר עזר בנושא תצורה של שרת proxy ל-API.

כתיבת סקריפטים מול ה-API

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

גלישת כלי הפריסה

קודם כל, צריך לוודא שכלי הפריסה של Python זמין בסביבה המקומית שלכם.

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

#!/bin/bash

org="Your ORG on enterprise.apigee.com"
username="Your USERNAME on enterprise.apigee.com"

# While testing, it's not necessary to change the setting below
env="test"
# Change the value below only if you have an on-premise deployment
url="https://api.enterprise.apigee.com"
# Change the value below only if you have a custom domain
api_domain="apigee.net"

export org=$org
export username=$username
export env=$env
export url=$url
export api_domain=$api_domain

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

עכשיו יוצרים סקריפט מעטפת שמייבא את ההגדרות האלה ומשתמש בהן כדי לקרוא לכלי הפריסה. (לדוגמה: דוגמאות לפלטפורמת API של Apigee).

#!/bin/bash

source path/to/setenv.sh

echo "Enter your password for the Apigee Enterprise organization $org, followed by [ENTER]:"

read -s password

echo Deploying $proxy to $env on $url using $username and $org

path/to/deploy.py -n {api_name} -u $username:$password -o $org -h $url -e $env -p / -d path/to/apiproxy

כדי להקל עליך מאוד, מומלץ ליצור גם סקריפט להפעלה ולבדיקה של ה-API באופן הבא:

#!/bin/bash

echo Using org and environment configured in /setup/setenv.sh

source /path/to/setenv.sh

set -x

curl "http://$org-$env.apigee.net/{api_basepath}"

הפעלה ישירה של ה-API

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

הסקריפט שלמטה מפעיל ישירות את ממשק ה-API לניהול. הוא מבטל את הפריסה הקיימת של שרת ה-Proxy של ה-API שאתם מעדכנים, יוצר קובץ ZIP מהספרייה /apiproxy שמכילה את קובצי התצורה של שרת ה-Proxy, ולאחר מכן מעלה, מייבאים ופורסים את התצורה.

#!/bin/bash

#This sets the name of the API proxy and the basepath where the API will be available
api=api

source /path/to/setenv.sh

echo Delete the DS_store file on OSX

echo find . -name .DS_Store -print0 | xargs -0 rm -rf
find . -name .DS_Store -print0 | xargs -0 rm -rf

echo "Enter your password for the Apigee Enterprise organization $org, followed by [ENTER]:"

read -s password

echo Undeploy and delete the previous revision

# Note that you need to explicitly update the revision to be undeployed.
# One benefit of the Python deploy tool is that it manages this for you.

curl -k -u $username:$password "$url/v1/o/$org/e/$env/apis/$api/revisions/1/deployments" -X DELETE

curl -k -u $username:$password -X DELETE "$url/v1/o/$org/apis/$api/revisions/1"

rm -rf $api.zip

echo Create the API proxy bundle and deploy

zip -r $api.zip apiproxy

echo Import the new revision to $env environment 

curl -k -v -u $username:$password "$url/v1/o/$org/apis?action=import&name=$api" -T $api.zip -H "Content-Type: application/octet-stream" -X POST

echo Deploy the new revision to $env environment 

curl -k -u $username:$password "$url/v1/o/$org/e/$env/apis/$api/revisions/1/deployments" -X POST