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

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

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

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

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

מידע מלא זמין במאמר Edge APIs.

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

  • ‫OAuth2 (ב-Public Cloud בלבד)
  • ‫SAML (ענן ציבורי וענן פרטי)
  • אימות בסיסי (לא מומלץ; ענן ציבורי וענן פרטי)

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

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

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

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

רשימת ממשקי API בארגון

אפשר להתחיל בהכנת רשימה של כל ה-API proxy בארגון. (חשוב להחליף את הערכים EMAIL:PASSWORD ו-ORG_NAME. הוראות מפורטות במאמר בנושא שימוש ב-Edge API.

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

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

[ "weatherapi" ]

קבלת API

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

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

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

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

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

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

קבלת גרסת API

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

הגרסה של שרת ה-proxy ל-API היא מספר עולה שמשויך להגדרות של שרת proxy ל-API. שירותי API שומרים את הגרסאות של ההגדרות, כך שאפשר לבטל הגדרה אם משהו משתבש. כברירת מחדל, המספר של הגרסה של שרת proxy ל-API גדל אוטומטית בכל פעם שמייבאים שרת proxy ל-API באמצעות ה-API של ייבוא שרת proxy ל-API. אם לא רוצים להגדיל את מספר הגרסה של proxy ל-API, משתמשים ב-API‏ Update API proxy revision. אם אתם משתמשים ב-Maven לפריסה, צריך להשתמש באפשרויות clean או update, כמו שמתואר בקובץ ה-Readme של Maven plugin.

לדוגמה, אפשר להפעיל את method‏ 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"
}

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

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

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

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

איך מציגים רשימה של סביבות

לכל ארגון ב-Apigee Edge יש לפחות שתי סביבות: test ו-prod. ההבחנה היא שרירותית. המטרה היא לספק לכם אזור שבו תוכלו לוודא ששרת ה-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 שנמצא במצב deployed יש גישה לרשת, בכתובות שמוגדרות ברכיב <VirtualHost> של הסביבה הזו.

פריסת ממשקי proxy ל-API

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

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

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

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

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

המאפיינים החשובים שמופיעים בתגובה הם 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 Proxy בכל הסביבות, משתמשים בשיטת ה-API הבאה:

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

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

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

נוצר פרופיל בשביל ה-proxy ל-API. ייצוג ברירת המחדל של שרת proxy ל-API הוא בפורמט JavaScript Object Notation ‏ (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"
}

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

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

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

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

סקריפטים שפועלים מול ה-API

במאמר Using the sample API proxies (שימוש בשרתי 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

הקובץ שלמעלה מאפשר לסקריפטים של מעטפת (shell) לעטוף את כלי הפריסה ולגשת לכל ההגדרות שלכם.

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

#!/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 באופן ישיר

יכול להיות שימושי לכתוב סקריפטים פשוטים של מעטפת שיהפכו את תהליך ההעלאה והפריסה של פרוקסי 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