درحال مشاهده اسناد Apigee Edge هستید.
به
اسناد Apigee X بروید. اطلاعات
هر سازمانی چرخه عمر توسعه نرمافزار (SDLC) منحصربهفردی دارد. اغلب لازم است استقرار پراکسی API با فرایندهای استفادهشده برای سرویسهای زیرینه همگامسازی و هماهنگ شود.
از روشهای «میانای برنامهسازی کاربردی Edge» که در این موضوع نشان داده شده است میتوان برای ادغام مدیریت پراکسی API در «چرخه توسعه نرمافزار» سازمانتان استفاده کرد. یکی از کاربردهای رایج این API نوشتن دستورگان یا کد برای استقرار پراکسیهای API یا انتقال پراکسیهای API از یک محیط به محیط دیگر بهعنوان بخشی از فرایند خودکارسازی بزرگتری است که برنامههای دیگر را نیز مستقر یا منتقل میکند.
Edge API هیچ فرضی درباره SDLC شما (یا هر کس دیگری) ندارد. بلکه، این API توابع اتمی را آشکار میکند که تیم توسعه شما میتواند آنها را هماهنگ کند تا چرخه حیات توسعه API شما را خودکارسازی و بهینه کند.
برای اطلاعات کامل، میاناهای برنامهسازی کاربردی Edge را ببینید.
برای استفاده از Edge API، باید خودتان را در تماسهایتان اصالتسنجی کنید. میتوانید این کار را با یکی از روشهای زیر انجام دهید:
- OAuth2 (فقط «ابر عمومی»)
- SAML (ابر عمومی و خصوصی)
- احراز هویت پایه (توصیه نمیشود؛ «ابر عمومی» و «ابر خصوصی»)
این موضوع بر مجموعه میاناهای برنامهسازی کاربردی که برای مدیریت پراکسیهای میانای برنامهسازی کاربردی هستند تمرکز دارد.
ویدیو: برای آشنایی با نحوه استقرار یک API، این ویدیو کوتاه را ببینید.
تعامل با «میانای برنامهسازی کاربردی»
مراحل زیر شما را در تعاملات ساده با «میاناهای برنامهسازی کاربردی» راهنمایی میکند.
فهرست کردن «میاناهای برنامهسازی کاربردی» در سازمان شما
میتوانید با فهرست کردن همه پراکسیهای API در سازمانتان شروع کنید. (بهخاطر داشته باشید که ورودیهای را برای EMAIL:PASSWORD و ORG_NAME جایگزین کنید. برای دریافت دستورالعملها، به استفاده از Edge API مراجعه کنید.
curl -u EMAIL:PASSWORD \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis
پاسخ نمونه:
[ "weatherapi" ]
دریافت میانای برنامهسازی کاربردی
میتوانید روش GET را در هر پراکسی 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، تغییر را برگردانید. همچنین میتوانید نسخه اصلاحشده یک پراکسی API را در محیط تولید مستقر کنید، درحالیکه به ایجاد نسخههای اصلاحشده جدید از آن پراکسی API در محیط آزمایش ادامه میدهید. وقتی آماده بودید، میتوانید نسخه بازبینی بالاتر کارگزار API خود را از محیط آزمایش به نسخه بازبینی قبلی کارگزار API در محیط تولید ارتقا دهید.
در این مثال، فقط یک بازبینی وجود دارد زیرا پراکسی API بهتازگی ایجاد شده است. وقتی کارگزار API از چرخه حیات پیکربندی و استقرار تکرارشونده عبور میکند، عدد بازبینی با اعداد صحیح افزایش مییابد. بااستفاده از فراخوانیهای مستقیم میانای برنامهسازی کاربردی برای استقرار، میتوانید بهصورت اختیاری عدد بازبینی میانای برنامهسازی کاربردی را افزایش دهید. گاهی اوقات وقتی تغییرات جزئی ایجاد میکنید، ممکن است نخواهید نسخه را افزایش دهید.
دریافت نسخه اصلاحشده میانای برنامهسازی کاربردی
نسخه «میانای برنامهسازی کاربردی» (برای نمونه، api.company.com/v1) باید بهندرت تغییر کند. وقتی نسخه میانای برنامهسازی کاربردی را افزایش میدهید، به توسعهدهندگان نشان میدهد که تغییر قابلتوجهی در امضای واسط خارجی که توسط میانای برنامهسازی کاربردی نمایان شده است رخ داده است.
نسخه پراکسی API یک عدد افزایشی مرتبط با پیکربندی پراکسی API است. «سرویسهای API» نسخههای بازبینی پیکربندیهای شما را حفظ میکند تا درصورت بروز مشکل بتوانید پیکربندی را به حالت قبل برگردانید. بهطور پیشفرض، هر بار که یک کارگزار پروکسی API را بااستفاده از API وارد کردن کارگزار پروکسی API وارد میکنید، نسخه اصلاحی کارگزار پروکسی API بهطور خودکار افزایش مییابد. اگر نمیخواهید نسخه بازبینی کارگزار نیابتی میانای برنامهسازی کاربردی را افزایش دهید، از میانای برنامهسازی کاربردی بهروزرسانی نسخه بازبینی کارگزار نیابتی میانای برنامهسازی کاربردی استفاده کنید. اگر از Maven برای استقرار استفاده میکنید، از گزینههای clean یا
update، همانطور که در فایل خودخوان افزایه Maven توضیح داده شده است، استفاده کنید.
برای مثال، میتوانید روش GET را در نسخه اصلاحشده 1 پراکسی 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 بهطور مفصل مستند شدهاند.
استقرار دادن میانای برنامهسازی کاربردی در محیط
پساز اینکه پراکسی API شما برای دریافت و بازارسال درست درخواستها پیکربندی شد، میتوانید آن را در یک یا چند محیط مستقر کنید. معمولاً در test روی پراکسیهای API تکرار میکنید و سپس، وقتی آماده شد،
نسخه اصلاحشده پراکسی API را به prod ارتقا میدهید. اغلب متوجه خواهید شد که نسخههای بازبینی بسیار بیشتری از پراکسی API در محیط آزمایش دارید، عمدتاً به این دلیل که تکرار بسیار کمتری در محیط تولید انجام خواهید داد.
تا زمانی که کارگزار نیابتی API در محیطی مستقر نشده باشد، نمیتوان آن را فراخوانی کرد. پساز اینکه
نسخه بازبینی کارگزار نیابتی API را در محیط تولید مستقر کردید، میتوانید نشانی وب prod را برای توسعهدهندگان
برونسازمانی منتشر کنید.
نحوه فهرست کردن محیطها
هر سازمان در Apigee Edge حداقل دو محیط دارد: test و prod. این
تمایز خودسرانه است. هدف این است که فضایی دراختیارتان قرار دهیم تا قبلاز اینکه پراکسی API خود را دراختیار توسعهدهندگان خارجی قرار دهید،
عملکرد صحیح آن را بررسی کنید.
هر محیط درواقع فقط یک نشانی شبکه است که به شما امکان میدهد ترافیک را بین پراکسیهای میانای برنامهسازی کاربردی که روی آنها کار میکنید و پراکسیهایی که برنامهها در زمان اجرا به آنها دسترسی دارند تفکیک کنید.
محیطها همچنین دادهها و منابع را تفکیک میکنند. برای مثال، میتوانید در محیطهای آزمایش و تولید، حافظههای نهان مختلفی راهاندازی کنید که فقط ازطریق پراکسیهای میانای برنامهسازی کاربردی که در آن محیط اجرا میشوند قابلدسترسی باشند.
مشاهده محیطها در سازمان
curl -u EMAIL:PASSWORD \ https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments
پاسخ نمونه
[ "test", "prod" ]
کاوش پیادهسازیها
استقرار یک بازبینی از پراکسی API است که در یک محیط مستقر شده است. کارگزار
میانای برنامهسازی کاربردی که در وضعیت استقراریافته باشد ازطریق شبکه و در نشانیهای تعریفشده در
عنصر <VirtualHost> برای آن محیط دردسترس است.
استقرار پراکسیهای میانای برنامهسازی کاربردی
تا زمانی که پراکسیهای API مستقر نشده باشند، نمیتوان آنها را فراخوانی کرد. «سرویسهای API» میاناهای برنامهسازی کاربردی RESTful را آشکار میکند که بر فرایند استقرار کنترل ارائه میدهد.
در هر زمان معین، فقط یک نسخه بازبینی از پراکسی 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
سپس نسخه جدید را مستقر کنید. نسخه جدید بازبینی کارگزار پراکسی 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 تنظیم کنید.
نمیتوانید یک نسخه مرور از پراکسی API را روی نسخه دیگری مستقر کنید. اولین مورد همیشه باید
ازهم باز شود. با تنظیم override روی true، نشان میدهید که یک بازبینی
از پراکسی 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 فاصله زمانی را برحسب ثانیه مشخص میکند که قبلاز آن نسخه قبلی باید لغو استقرار شود. تأثیر این است که تراکنشهای درحال انجام یک بازه زمانی دارند که در آن باید تکمیل شوند،
وگرنه کارگزار میانای برنامهسازی کاربردی که تراکنش آنها را پردازش میکند ازکار میافتد. در ادامه
آنچه با override=true و پارامتر delay تنظیمشده رخ میدهد آمده است:
- نسخه ۱ درحال رسیدگی به درخواستها است.
- نسخه اصلاحشده ۲ بهصورت موازی درحال استقرار است.
- وقتی «بازبینی ۲» بهطور کامل مستقر شد، ترافیک جدید به «بازبینی ۲» ارسال میشود. ترافیک جدیدی به «بازبینی ۱» ارسال نمیشود.
- بااینحال، «بازبینی ۱» ممکن است همچنان درحال پردازش تراکنشهای موجود باشد. با تنظیم پارامتر
delay(برای مثال، ۱۵ ثانیه)، به «نسخه اصلاحشده ۱» ۱۵ ثانیه فرصت میدهید تا پردازش تراکنشهای موجود را تمام کند. - پساز فاصله تأخیر، «نسخه اصلاحشده ۱» لغو استقرار میشود.
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 |
پیشفرض برای ملغی کردن رفتار استقرار عادی و ارائه استقرار یکپارچه، روی |
delay |
برای اینکه پردازش تراکنش در نسخه اصلاحشده موجود قبلاز
برداشتن استقرار تکمیل شود—و احتمال پیشفرض ۰ (صفر) ثانیه است. وقتی |
وقتی override=true همراه با delay استفاده میشود، پاسخهای HTTP 5XX
درطول استقرار میتواند حذف شود. دلیل این است که هر دو نسخه بازبینی کارگزار نیابتی API بهطور همزمان
مستقر میشوند و نسخه بازبینی قدیمیتر پساز تأخیر مستقر نمیشود.
دیدن همه استقرارها در نسخه API
گاهی لازم است فهرستی از همه نسخههای بازبینی استقراریافته فعلی یک پراکسی 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. با
مرور کردن این مقادیر دارایی، میتوانید تأیید کنید که نسخه اصلاحشده خاصی از پراکسی API در محیطی
استقرار یافته است.
دیدن همه استقرارها در محیط آزمایش
همچنین میتوانید وضعیت استقرار را برای محیطی خاص (ازجمله شماره بازبینی کارگزار پراکسی API مستقرشده فعلی) بااستفاده از تماس زیر بازیابی کنید:
curl -u EMAIL:PASSWORD https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/test/deployments
این دستور همان نتیجه بالا را برای هر API مستقرشده در محیط آزمایش برمیگرداند
دیدن همه استقرارها در سازمان شما
برای واکشی فهرست همه نسخههای پیادهسازیشده فعلی همه پراکسیهای API در همه محیطها، از روش API زیر استفاده کنید:
curl https://api.enterprise.apigee.com/v1/o/ORG_NAME/deployments \ -u EMAIL:PASSWORD
این دستور همان نتیجه بالا را برای همه پراکسیهای API که در همه محیطها مستقر شدهاند برمیگرداند.
ازآنجاییکه API از نوع RESTful است، میتوانید بهسادگی از روش POST، بههمراه دادهبر JSON یا XML
دربرابر همان منبع برای ایجاد پراکسی API استفاده کنید.
نمایهای برای پراکسی API شما تولید میشود. نمایش پیشفرض پراکسی API در
نشانگذاری شیء جاوا اسکریپت (JSON) است. در زیر پاسخ JSON پیشفرض به درخواست POST در بالا آمده است که یک پراکسی 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" }
نمایه پراکسی میانای برنامهسازی کاربردی تولیدشده ساختار کامل پراکسی میانای برنامهسازی کاربردی را نشان میدهد:
APIProxy revision: تکرار شمارهگذاری ترتیبی پیکربندی پراکسی API که توسط «خدمات API» نگهداری میشود-
APIProxy name: نام یکتای پراکسی API ConfigurationVersion: نسخه «سرویسهای API» که پیکربندی کارگزار API با آن مطابقت دارد-
CreatedAt: زمان تولید پراکسی میانای برنامهسازی کاربردی، قالببندیشده در زمان یونیکس CreatedBy: نشانی ایمیل کاربر Apigee Edge که پراکسی API را ایجاد کرده است-
DisplayName: نام کاربرپسند برای پراکسی API -
LastModifiedAt: زمان تولید پراکسی میانای برنامهسازی کاربردی، قالببندیشده در زمان یونیکس LastModifiedBy: نشانی ایمیل کاربر Apigee Edge که پراکسی API را ایجاد کرده استPolicies: فهرستی از خطمشیهایی که به این پراکسی API اضافه شده استProxyEndpoints: فهرستی از ProxyEndpoints نامگذاریشده-
Resources: فهرستی از منابع (JavaScript، Python، Java، XSLT) که برای اجرا در این پراکسی API دردسترس است TargetServers: فهرستی از «سرورهای هدف» نامگذاریشده (که میتوانند بااستفاده از management API ایجاد شوند)، که در پیکربندیهای پیشرفته برای اهداف تراز بار استفاده میشوندTargetEndpoints: فهرستی از «نقطههای پایانی هدف» نامگذاریشده
توجه داشته باشید که بسیاری از عناصر پیکربندی پراکسی API که بااستفاده از روش ساده POST
در بالا ایجاد شدهاند، خالی هستند. در موضوعات زیر، با نحوه افزودن و پیکربندی کردن اجزای کلیدی
پراکسی API آشنا خواهید شد.
همچنین میتوانید درباره این عناصر پیکربندی در مرجع پیکربندی پراکسی API بخوانید.
دستورگاننویسی دربرابر میانای برنامهسازی کاربردی
استفاده از پراکسیهای 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
فایل بالا همه تنظیمات شما را برای دستورات پوسته که ابزار استقرار را میپیچند دردسترس قرار میدهد.
اکنون دستورگان پوستهای ایجاد کنید که آن تنظیمات را وارد میکند و از آنها برای فراخوانی ابزار پیادهسازی استفاده میکند. (برای نمونه، نمونههای پلاتفرم 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
برای اینکه کارتان واقعاً آسان شود، یک دستورگان هم برای فراخوانی و آزمایش کردن «میانای برنامهسازی کاربردی» ایجاد کنید، به این صورت: :
#!/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 مدیریت را فراخوانی میکند. نسخه اصلاحشده موجود از
پراکسی API را که درحال بهروزرسانی آن هستید لغو استقرار میکند، از دایرکتوری /apiproxy
حاوی فایلهای پیکربندی پراکسی شما فایل ZIP ایجاد میکند، و سپس پیکربندی را
بارگذاری، وارد، و مستقر میکند.
#!/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