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

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

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

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 בסביבת הבדיקה, בעיקר מפני שתעשו הרבה פחות בסביבת prod.

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

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

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

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

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

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

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

תשובה לדוגמה

[ "test", "prod" ]

בדיקת הפריסות

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

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

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

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

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

קודם כול צריך לבטל את הפריסה של הגרסה הקיימת. מציינים את שם הסביבה ואת מספר הגרסה של שרת ה-proxy ל-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 גרסה קודמת

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

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 קצה. אם אתם לא משתמשים ב-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 שנפרס בסביבת הבדיקה

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

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

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

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

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

נוצר פרופיל עבור ה-Proxy ל-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"
}

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

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

חשוב לשים לב שהרבה מהרכיבים של תצורת ה-Proxy ל-API נוצרו באמצעות רכיב ה-POST הפשוט ה-methods שלמעלה ריקות. בנושאים הבאים נסביר איך להוסיף ולהגדיר מפתח רכיבים של שרת 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

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

עכשיו יוצרים סקריפט מעטפת שמייבא את ההגדרות האלה ומשתמש בהן כדי לקרוא לכלי הפריסה. (לדוגמה, דוגמאות של פלטפורמות 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.

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