API-Proxys mithilfe der API bereitstellen

Sie lesen gerade die Dokumentation zu Apigee Edge.
Zur Dokumentation zu Apigee X. info

Jede Organisation hat einen eigenen Software-Entwicklungslebenszyklus (SDLC). Häufig muss die API-Proxy-Bereitstellung mit den für Back-End-Dienste verwendeten Prozessen synchronisiert und ausgerichtet werden.

Die in diesem Thema beschriebenen Edge API-Methoden können verwendet werden, um die API-Proxy Verwaltung in den SDLC Ihrer Organisation zu integrieren. Eine gängige Verwendung dieser API besteht darin, Skripts oder Code zu schreiben, die API-Proxys bereitstellen oder API-Proxys von einer Umgebung in eine andere migrieren, als Teil eines größeren automatisierten Prozesses, der auch andere Anwendungen bereitstellt oder migriert.

Die Edge API macht keine Annahmen zu Ihrem SDLC (oder dem eines anderen). Stattdessen werden atomare Funktionen bereitgestellt, die von Ihrem Entwicklungsteam koordiniert werden können, um den API-Entwicklungszyklus zu automatisieren und zu optimieren.

Vollständige Informationen finden Sie unter Edge APIs.

Wenn Sie die Edge API verwenden möchten, müssen Sie sich in Ihren Aufrufen authentifizieren. Dazu haben Sie folgende Möglichkeiten:

In diesem Thema geht es um die APIs zur Verwaltung von API-Proxys.

Video:Sehen Sie sich dieses Kurzvideo an, um zu erfahren, wie Sie eine API bereitstellen.

Mit der API interagieren

Die folgenden Schritte führen Sie durch einfache Interaktionen mit den APIs.

APIs in Ihrer Organisation auflisten

Sie können zuerst alle API-Proxys in Ihrer Organisation auflisten. (Denken Sie daran, die Einträge für EMAIL:PASSWORD und ORG_NAME zu ersetzen. Eine Anleitung finden Sie unter Edge API verwenden.

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

Beispielantwort:

[ "weatherapi" ]

API abrufen

Sie können die Methode GET für jeden API-Proxy in Ihrer Organisation aufrufen. Dieser Aufruf gibt eine Liste aller verfügbaren Überarbeitungen des API-Proxys zurück.

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

Beispielantwort:

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

Das einzige Detail, das von dieser Methode zurückgegeben wird, ist der Name des API-Proxys zusammen mit der zugehörigen Überarbeitung, die eine zugehörige Nummer hat. API-Proxys bestehen aus einem Bundle von Konfigurations dateien. Überarbeitungen bieten einen einfachen Mechanismus zum Verwalten der Aktualisierungen der Konfiguration während Sie iterieren. Überarbeitungen werden sequenziell nummeriert, sodass Sie eine Änderung rückgängig machen können, indem Sie eine vorherige Überarbeitung Ihres API-Proxys bereitstellen. Sie können auch eine Überarbeitung eines API-Proxys in der Produktionsumgebung bereitstellen und gleichzeitig neue Überarbeitungen dieses API-Proxys in der Test Umgebung erstellen. Wenn Sie fertig sind, können Sie die neuere Überarbeitung Ihres API-Proxys über die Testumgebung der vorherigen Überarbeitung des API-Proxys in der Produktionsumgebung hochschalten.

In diesem Beispiel gibt es nur eine Überarbeitung, da der API-Proxy gerade erst erstellt wurde. Wenn ein API Proxy den Lebenszyklus der iterativen Konfiguration und Bereitstellung durchläuft, wird die Überarbeitungsnummer um ganze Zahlen erhöht. Wenn Sie API-Proxys mit direkten API-Aufrufen bereitstellen, können Sie die Überarbeitungsnummer optional erhöhen. Manchmal möchten Sie die Überarbeitung bei kleineren Änderungen nicht erhöhen.

API-Überarbeitung abrufen

Die API-Version (z. B. api.company.com/v1) sollte sich nur sehr selten ändern. Wenn Sie die API-Version erhöhen, signalisieren Sie Entwicklern, dass es eine erhebliche Änderung an der Signatur der externen Schnittstelle gegeben hat, die von der API bereitgestellt wird.

Die API-Proxy-Version ist eine inkrementelle Nummer, die einer API-Proxy-Konfiguration zugeordnet ist. API-Dienste verwalten Überarbeitungen Ihrer Konfigurationen, damit Sie eine Konfiguration rückgängig machen können, wenn etwas schiefgeht. Standardmäßig wird die Überarbeitung eines API-Proxys automatisch erhöht, wenn Sie einen API-Proxy mit der API API-Proxy importieren importieren. Wenn Sie die Überarbeitung eines API-Proxys nicht erhöhen möchten, verwenden Sie die API-Proxy-Überarbeitung aktualisieren API. Wenn Sie Maven für die Bereitstellung verwenden, verwenden Sie die clean oder update Optionen, wie in der Maven-Plug-in Readme-Datei beschrieben.

Sie können beispielsweise die Methode GET für die API-Proxy-Version 1 aufrufen, um eine detaillierte Ansicht zu erhalten.

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

Beispielantwort

{
  "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"
}

Diese Elemente der API-Proxy-Konfiguration werden in der Referenz zur API-Proxy-Konfiguration ausführlich dokumentiert.

API in einer Umgebung bereitstellen

Sobald Ihr API-Proxy so konfiguriert ist, dass er Anfragen ordnungsgemäß empfängt und weiterleitet, können Sie ihn in einer oder mehreren Umgebungen bereitstellen. Normalerweise iterieren Sie API-Proxys in test und dann, wenn bereit, _schalten_ Sie die API-Proxy-Überarbeitung auf prod hoch. Oft haben Sie viel mehr Überarbeitungen eines API-Proxys in der Testumgebung, vor allem, weil Sie in der Produktionsumgebung viel weniger iterieren.

Ein API-Proxy kann erst aufgerufen werden, nachdem er in einer Umgebung bereitgestellt wurde. Nachdem Sie die API-Proxy-Überarbeitung in der Produktionsumgebung bereitgestellt haben, können Sie die prod URL für externe Entwickler veröffentlichen.

Umgebungen auflisten

Jede Organisation in Apigee Edge hat mindestens zwei Umgebungen: test und prod. Die Unterscheidung ist willkürlich. Ziel ist es, Ihnen einen Bereich zur Verfügung zu stellen, in dem Sie prüfen können, ob Ihr API-Proxy ordnungsgemäß funktioniert, bevor Sie ihn für externe Entwickler öffnen.

Jede Umgebung ist nur eine Netzwerkadresse, sodass Sie den Traffic zwischen den API-Proxys, an denen Sie arbeiten, und denen, die von Anwendungen zur Laufzeit aufgerufen werden, aufteilen können.

Umgebungen bieten auch die Trennung von Daten und Ressourcen. Sie können beispielsweise verschiedene Caches in Test und Produktion einrichten, auf die nur von API-Proxys zugegriffen werden kann, die in dieser Umgebung ausgeführt werden.

Umgebungen in einer Organisation ansehen

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

Beispielantwort

[ "test", "prod" ]

Deployments analysieren

Eine Bereitstellung ist eine Überarbeitung eines API-Proxys, die in einer Umgebung bereitgestellt wurde. Ein API Proxy im Status bereitgestellt ist über das Netzwerk unter den Adressen zugänglich, die in dem <VirtualHost> Element für diese Umgebung definiert sind.

API-Proxys bereitstellen

API-Proxys können erst aufgerufen werden, nachdem sie bereitgestellt wurden. API-Dienste stellen RESTful APIs bereit, mit denen Sie den Bereitstellungsprozess steuern können.

Es kann jeweils nur eine Überarbeitung eines API-Proxys in einer Umgebung bereitgestellt werden. Daher muss die Bereitstellung der bereitgestellten Überarbeitung aufgehoben werden. Sie können festlegen, ob das neue Bundle als neue Überarbeitung bereitgestellt werden soll oder ob es die vorhandene Überarbeitung überschreiben soll.

Sie lesen gerade die Apigee Edge -Dokumentation.
Zur Apigee X -Dokumentation. info

Heben Sie zuerst die Bereitstellung der vorhandenen Überarbeitung auf. Geben Sie den Umgebungsnamen und die Überarbeitungsnummer des API-Proxys an, dessen Bereitstellung Sie aufheben möchten:

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

Stellen Sie dann die neue Überarbeitung bereit. Die neue Überarbeitung des API-Proxys muss bereits vorhanden sein: 

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

Nahtlose Bereitstellung (keine Ausfallzeiten)

Verwenden Sie den Parameter override für die Bereitstellungsmethode und legen Sie ihn auf true fest, um die potenziellen Ausfallzeiten während der Bereitstellung zu minimieren.

Sie können nicht eine Überarbeitung eines API-Proxys über einer anderen bereitstellen. Die erste muss immer bereitgestellt werden. Wenn Sie override auf true setzen, geben Sie an, dass eine Überarbeitung eines API-Proxys über der derzeit bereitgestellten Überarbeitung bereitgestellt werden soll. Das Ergebnis ist, dass die Bereitstellungsreihenfolge umgekehrt wird: Die neue Überarbeitung wird bereitgestellt und sobald die Bereitstellung abgeschlossen ist, wird die Bereitstellung der bereits bereitgestellten Überarbeitung aufgehoben.

Im folgenden Beispiel wird der Wert override festgelegt, indem er als Formularparameter übergeben wird: 

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

Sie können die Bereitstellung weiter optimieren, indem Sie den Parameter delay festlegen. Der delay Parameter gibt ein Zeitintervall in Sekunden an, vor dem die Bereitstellung der vorherigen Überarbeitung aufgehoben werden soll. Dadurch haben laufende Transaktionen ein Zeitintervall, in dem sie abgeschlossen werden können, bevor die Bereitstellung des API-Proxys, der die Transaktion verarbeitet, aufgehoben wird. Folgendes geschieht mit override=true und dem festgelegten Parameter delay:

  • Überarbeitung 1 verarbeitet Anfragen.
  • Überarbeitung 2 wird parallel bereitgestellt.
  • Wenn die Bereitstellung von Überarbeitung 2 abgeschlossen ist, wird neuer Traffic an Überarbeitung 2 gesendet. An Überarbeitung 1 wird kein neuer Traffic gesendet.
  • Überarbeitung 1 verarbeitet jedoch möglicherweise noch vorhandene Transaktionen. Wenn Sie den delay Parameter festlegen (z. B. 15 Sekunden), hat Überarbeitung 1 15 Sekunden Zeit, um die Verarbeitung vorhandener Transaktionen abzuschließen.
  • Nach dem Verzögerungsintervall wird die Bereitstellung von Überarbeitung 1 aufgehoben.
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
Suchparameter Beschreibung
override

Der Standardwert ist false (normales Bereitstellungsverhalten: Die Bereitstellung der vorhandenen Überarbeitung wird aufgehoben, dann wird die neue Überarbeitung bereitgestellt).

Setzen Sie den Wert auf true, um das normale Bereitstellungsverhalten zu überschreiben und eine nahtlose Bereitstellung zu ermöglichen. Die vorhandene Überarbeitung bleibt bereitgestellt, während die neue Überarbeitung ebenfalls bereitgestellt wird. Wenn die neue Überarbeitung bereitgestellt ist, wird die Bereitstellung der alten Überarbeitung aufgehoben. Verwenden Sie diesen Parameter zusammen mit dem Parameter delay, um zu steuern, wann die Bereitstellung aufgehoben wird.
delay

Wenn Sie möchten, dass die Transaktionsverarbeitung für die vorhandene Überarbeitung abgeschlossen wird, bevor die Bereitstellung aufgehoben wird, und die Möglichkeit von 502 Bad Gateway oder 504 Gateway Timeout errors vermeiden möchten, legen Sie diesen Parameter auf die Anzahl der Sekunden fest, um die die Bereitstellung aufgehoben werden soll. Die Anzahl der Sekunden, die Sie festlegen können, ist nicht begrenzt. Das Festlegen einer großen Anzahl von Sekunden hat keine Auswirkungen auf die Leistung. Während der Verzögerung wird kein neuer Traffic an die alte Überarbeitung gesendet.

Der Standardwert ist 0 (null) Sekunden. Wenn override auf „true“ und delay auf 0 gesetzt ist, wird die Bereitstellung der vorhandenen Überarbeitung sofort aufgehoben, nachdem die neue Überarbeitung bereitgestellt wurde. Negative Werte werden als 0 (null) Sekunden behandelt.

Wenn override=true zusammen mit einer delay verwendet wird, können HTTP-5XX -Antworten während der Bereitstellung vermieden werden. Das liegt daran, dass beide API-Proxy-Überarbeitungen gleichzeitig bereitgestellt werden, wobei die Bereitstellung der älteren Überarbeitung nach der Verzögerung aufgehoben wird.

Alle Bereitstellungen einer API Überarbeitung ansehen

Manchmal ist es erforderlich, eine Liste aller derzeit bereitgestellten Überarbeitungen eines API Proxys abzurufen.

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"
}

Die Antwort oben enthält viele Eigenschaften, die spezifisch für die interne Infrastruktur von Apigee Edge sind. Sofern Sie Apigee Edge nicht lokal verwenden, können Sie diese Einstellungen nicht ändern.

Die wichtigen Eigenschaften in der Antwort sind organization, environment, aPIProxy, name, und state. Anhand dieser Eigenschaftswerte können Sie bestätigen, dass eine bestimmte Überarbeitung eines API-Proxys in einer Umgebung bereitgestellt ist.

Alle Bereitstellungen in der Testumgebung ansehen

Mit dem folgenden Aufruf können Sie auch den Bereitstellungsstatus für eine bestimmte Umgebung abrufen, einschließlich der Überarbeitungs nummer des derzeit bereitgestellten API-Proxys:

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

Dadurch wird für jede in der Testumgebung bereitgestellte API dasselbe Ergebnis wie oben zurückgegeben.

Alle Bereitstellungen in Ihrer Organisation ansehen

Verwenden Sie die folgende API-Methode, um eine Liste aller derzeit bereitgestellten Überarbeitungen aller API-Proxys in allen Umgebungen abzurufen:

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

Dadurch wird für alle API-Proxys, die in allen Umgebungen bereitgestellt wurden, dasselbe Ergebnis wie oben zurückgegeben.

Da die API RESTful ist, können Sie einfach die POST Methode zusammen mit einer JSON- oder XML Nutzlast für dieselbe Ressource verwenden, um einen API-Proxy zu erstellen.

Ein Profil für Ihren API-Proxy wird generiert. Die Standarddarstellung eines API-Proxys ist in JavaScript Object Notation (JSON). Unten sehen Sie die Standard-JSON-Antwort auf die POST Anfrage oben, mit der ein API-Proxy namens weatherapi erstellt wurde. Im Folgenden finden Sie eine Beschreibung der einzelnen Elemente im Profil folgt:

{
  "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"
}

Das generierte API-Proxy-Profil zeigt die vollständige Struktur eines API Proxys:

  • APIProxy revision: Die sequenziell nummerierte Überarbeitung der API-Proxy-Konfiguration, wie sie von API-Diensten verwaltet wird
  • APIProxy name: Der eindeutige Name des API-Proxys
  • ConfigurationVersion: API-Dienste-Version, der die API-Proxy Konfiguration entspricht
  • CreatedAt: Zeitpunkt, zu dem der API-Proxy generiert wurde, formatiert in UNIX-Zeit
  • CreatedBy: E-Mail-Adresse des Apigee Edge-Nutzers, der den API Proxy erstellt hat
  • DisplayName: Ein benutzerfreundlicher Name für den API-Proxy
  • LastModifiedAt: Zeitpunkt, zu dem der API-Proxy generiert wurde, formatiert in UNIX Zeit
  • LastModifiedBy: E-Mail-Adresse des Apigee Edge-Nutzers, der den API Proxy erstellt hat
  • Policies: Eine Liste der Richtlinien, die diesem API-Proxy hinzugefügt wurden
  • ProxyEndpoints: Eine Liste benannter ProxyEndpoints
  • Resources: Eine Liste der Ressourcen (JavaScript, Python, Java, XSLT), die in diesem API-Proxy ausgeführt werden können
  • TargetServers: Eine Liste benannter TargetServers (die mit der Management API erstellt werden können) für erweiterte Konfigurationen zur Lastverteilung
  • TargetEndpoints: Eine Liste benannter TargetEndpoints

Viele der Elemente der API-Proxy-Konfiguration, die mit der einfachen POST -Methode oben erstellt wurden, sind leer. In den folgenden Themen erfahren Sie, wie Sie die wichtigsten Komponenten eines API-Proxys hinzufügen und konfigurieren.

Weitere Informationen zu diesen Konfigurationselementen finden Sie in der Referenz zur API-Proxy-Konfiguration.

Skripts für die API

Die Beispiel-API-Proxys, auf GitHub enthalten Shell-Skripts, die das Apigee-Bereitstellungstool umschließen. Wenn Sie das Python-Bereitstellungstool aus irgendeinem Grund nicht verwenden können, können Sie die API direkt aufrufen. Beide Ansätze werden in den folgenden Beispielskripts veranschaulicht.

Bereitstellungstool umschließen

Prüfen Sie zuerst, ob das Python-Bereitstellungstool in Ihrer lokalen Umgebung verfügbar ist.

Erstellen Sie dann eine Datei für Ihre Anmeldedaten. Die von Ihnen erstellten Bereitstellungsskripts importieren diese Einstellungen, sodass Sie die Anmeldedaten für Ihr Konto zentral verwalten können. Im Beispiel für die API Plattform heißt diese Datei 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

Die Datei oben stellt alle Ihre Einstellungen für die Shell-Skripts zur Verfügung, die das Bereitstellungstool umschließen.

Erstellen Sie jetzt ein Shell-Skript, das diese Einstellungen importiert und damit das Bereitstellungstool aufruft. Ein Beispiel finden Sie unter Apigee API Platform-Beispiele.

#!/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

Um die Arbeit zu erleichtern, erstellen Sie auch ein Skript zum Aufrufen und Testen der API, wie folgt:

#!/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 direkt aufrufen

Es kann nützlich sein, einfache Shell-Skripts zu schreiben, die das Hochladen und Bereitstellen von API-Proxys automatisieren.

Das folgende Skript ruft die Management API direkt auf. Es hebt die Bereitstellung der vorhandenen Überarbeitung des API-Proxys auf, den Sie aktualisieren, erstellt eine ZIP-Datei aus dem /apiproxy Verzeichnis mit Ihren Proxy-Konfigurationsdateien und lädt dann die Konfiguration hoch, importiert und stellt sie bereit.

#!/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