Referenz zur API-Proxy-Konfiguration

Sie sehen die Dokumentation zu Apigee Edge.
Rufen Sie die Apigee X-Dokumentation auf.
weitere Informationen

Als Entwickler, der mit Apigee Edge arbeitet, umfassen Ihre primären Entwicklungsaktivitäten die Konfiguration von API-Proxys, die als Proxys für APIs oder Back-End-Dienste fungieren. Dieses Dokument enthält eine Referenz aller Konfigurationselemente, die Ihnen beim Erstellen von API-Proxys zur Verfügung stehen.

Wenn Sie lernen, API-Proxys zu erstellen, sollten Sie mit dem Thema Einfachen API-Proxy erstellen beginnen.

Die gängigsten Methoden zum Bearbeiten von Proxy-Konfigurationen sind:

Lokale Entwicklung von Proxy-Konfigurationen

Sie können Ihre Proxykonfigurationen herunterladen, um sie auf einem lokalen Computer bearbeiten zu können. Wenn Sie fertig sind, laden Sie die Ergebnisse in Edge hoch. Auf diese Weise können Sie die Proxykonfigurationen in Ihre Versionsverwaltung, Versionsverwaltung und andere freigegebene Workflows integrieren. Wenn Sie lokal an einer Proxykonfiguration arbeiten, können Sie außerdem Ihren eigenen XML-Editor und Validierungstools verwenden.

In diesem Abschnitt wird beschrieben, wie Sie über die Benutzeroberfläche eine vorhandene Proxy-Konfiguration herunterladen, bearbeiten und dann zur Bereitstellung wieder in Edge hochladen. Außerdem können Sie mit apigeetool eine neue Proxykonfiguration herunterladen und bereitstellen (mithilfe der Befehle fetchproxy bzw. deployproxy).

So bearbeiten Sie eine Proxykonfiguration lokal über die Benutzeroberfläche:

  1. Laden Sie die aktuelle Proxykonfiguration in der Edge-Benutzeroberfläche herunter. (Wählen Sie in der Ansicht „API-Proxys“ die Option Projekt > Überarbeitung herunterladen aus.)
  2. Erstellen Sie auf Ihrem lokalen Computer ein neues Verzeichnis und erweitern Sie die heruntergeladene ZIP-Datei darin.

    Zum Erweitern der ZIP-Datei können Sie ein Dienstprogramm wie unzip verwenden, wie im folgenden Beispiel gezeigt:

    mkdir myappdir
    unzip ./my-app_app_rev3_2019_04_20.zip -d myappdir

    Der maximierte Inhalt der ZIP-Datei sollte der unter API-Proxy-Struktur beschriebenen Struktur ähneln.

  3. Bearbeiten Sie die Quelldateien nach Bedarf. Eine Beschreibung der Quelldateien in einer Proxykonfiguration finden Sie unter Konfigurationsdateien und die Verzeichnisstruktur eines API-Proxys.

    Wenn Sie beispielsweise das Statusmonitoring in Ihrem API-Proxy aktivieren möchten, bearbeiten Sie die Konfigurationsdatei "TargetEndpoint" im Verzeichnis /apiproxy/targets/. Die Standarddatei in diesem Verzeichnis ist default.xml. Wenn Sie jedoch bedingte Ziele verwenden, können Dateien mit anderen Namen vorhanden sein.

    Erstellen Sie in diesem Fall die neue TargetEndpoint-Konfigurationsdatei und das zugehörige Verzeichnis.

  4. Nachdem Sie die Proxykonfigurationsdateien bearbeitet haben, speichern Sie Ihre Änderungen.
  5. Wechseln Sie in das neue Verzeichnis, das Sie beim Maximieren der ZIP-Dateien (das Stammverzeichnis der erweiterten Konfigurationsdateien) erstellt haben.

    Wenn Sie die Dateien beispielsweise in das Verzeichnis /myappdir erweitert haben, wechseln Sie in dieses Verzeichnis, wie im folgenden Beispiel gezeigt:

    cd myappdir

    Wechseln Sie in dieses Verzeichnis, bevor Sie Ihre Proxykonfigurationsdateien neu archivieren, da das Verzeichnis /myappdir nicht in der ZIP-Datei enthalten sein soll. Das Verzeichnis der obersten Ebene in der ZIP-Datei muss /apiproxy sein.

  6. Archivieren Sie die Proxykonfigurationsdateien neu, einschließlich der neuen oder geänderten Dateien. Sie können ein Dienstprogramm wie zip verwenden, wie im folgenden Beispiel gezeigt:
    zip my-new-proxy.zip -r .

    Das Verzeichnis der obersten Ebene in der ZIP-Datei muss /apiproxy sein.

    Für den Namen der ZIP-Datei gibt es keine besonderen Anforderungen. Es ist beispielsweise nicht erforderlich, die Überarbeitungsnummer zu erhöhen oder das Datum im Dateinamen anzugeben. Dies kann jedoch für die Fehlerbehebung oder die Versionsverwaltung nützlich sein.

    Edge erhöht die Versionsnummer der neuen Proxykonfiguration beim Hochladen für Sie.

  7. Laden Sie die neue Proxykonfiguration mithilfe der Edge-Benutzeroberfläche hoch. Wählen Sie in der Ansicht API-Proxys die Option Projekt > Neue Überarbeitung hochladen aus.

    Wenn ein Fehler wie Bundle is invalid. Empty bundle. angezeigt wird, prüfen Sie, ob das oberste Verzeichnis Ihrer ZIP-Datei /apiproxy ist. Ist dies nicht der Fall, archivieren Sie Ihre Proxykonfigurationsdateien erneut aus dem Stammverzeichnis des erweiterten Verzeichnisses.

    Nach dem Hochladen der neuen Proxykonfiguration erhöht Edge die Überarbeitungsnummer und zeigt sie in der Ansicht Versionsübersicht an.

    Edge stellt die neue Überarbeitung nicht für Sie bereit, nachdem Sie sie über die Benutzeroberfläche hochgeladen haben.

  8. Stellen Sie Ihre neue Überarbeitung bereit.

Weitere Informationen finden Sie in der Apigee-Community unter Anleitung: Proxy mit der Benutzeroberfläche und der Verwaltungs-API herunterladen.

API-Proxystruktur

Ein API-Proxy besteht aus der folgenden Konfiguration:

Basiskonfiguration Primäre Konfigurationseinstellungen für einen API-Proxy Siehe Basiskonfiguration.
ProxyEndpoint-Konfiguration Einstellungen für die eingehende HTTP-Verbindung (von der Anforderung von Anwendungen an Apigee Edge), die Anforderungs- und Antwortabläufe sowie die Richtlinienanhänge. Siehe ProxyEndpoint.
TargetEndpoint-Konfiguration Einstellungen für die ausgehende HTTP-Verbindung (von Apigee Edge zum Backend-Dienst), Anfrage- und Antwortabläufe sowie Richtlinienanhänge. Weitere Informationen finden Sie unter TargetEndpoint.
Abläufe ProxyEndpoint- und TargetEndpoint-Anfragen und Antwortpipelines, an die Richtlinien angehängt werden können. Siehe Abläufe.
Richtlinien XML-formatierte Konfigurationsdateien, die den Apigee Edge-Richtlinienschemas entsprechen. Siehe Richtlinien.
Ressourcen Skripts, JAR-Dateien und XP-Dateien, auf die von Richtlinien verwiesen wird, um benutzerdefinierte Logik auszuführen Ressourcen ansehen.

API-Proxy-Verzeichnisstruktur und -Inhalte

Die Komponenten in der obigen Tabelle werden durch Konfigurationsdateien in der folgenden Verzeichnisstruktur definiert:

Zeigt die Verzeichnisstruktur an, in der "apiproxy" der Stamm ist. Direkt unter dem apiproxy-Verzeichnis finden Sie die Richtlinien, Proxys, Ressourcen und Zielverzeichnisse sowie die Datei "weatherapi.xml".

Konfigurationsdateien und Verzeichnisstruktur eines API-Proxys

In diesem Abschnitt werden die Konfigurationsdateien und die Verzeichnisstruktur eines API-Proxys erläutert.

Basiskonfiguration

/apiproxy/weatherapi.xml

Die Basiskonfiguration für einen API-Proxy, der den Namen des API-Proxys definiert. Der Name muss innerhalb einer Organisation eindeutig sein.

Beispielkonfiguration:

<APIProxy name="weatherapi">
</APIProxy>

Basiskonfigurationselemente

Name Beschreibung Standard Erforderlich?
APIProxy
name Der Name des API-Proxys, der innerhalb einer Organisation eindeutig sein muss. Die Zeichen, die Sie im Namen verwenden dürfen, sind auf folgende Zeichen beschränkt: A-Za-z0-9_- Ja
revision Die Überarbeitungsnummer der API-Proxykonfiguration. Sie müssen die Überarbeitungsnummer nicht explizit festlegen, da Apigee Edge die aktuelle Version des API-Proxys automatisch verfolgt. Nein
ConfigurationVersion Die Version des API-Proxykonfigurationsschemas, dem dieser API-Proxy entspricht. Der einzige unterstützte Wert ist derzeit "majorVersion 4" und "minorVersion 0". Diese Einstellung kann später verwendet werden, um die Weiterentwicklung des API-Proxyformats zu ermöglichen. 4.0 Nein
Description Eine Textbeschreibung des API-Proxys. Wenn angegeben, wird die Beschreibung in der Edge-Verwaltungs-UI angezeigt. Nein
DisplayName Ein nutzerfreundlicher Name, der sich vom Attribut name der API-Proxykonfiguration unterscheiden kann. Nein
Policies Eine Liste der Richtlinien im Verzeichnis /policies dieses API-Proxys. Normalerweise wird dieses Element nur angezeigt, wenn der API-Proxy mit der Edge-Verwaltungs-UI erstellt wurde. Dies ist einfach eine Manifest-Einstellung, die Einblick in den Inhalt des API-Proxys bietet. Nein
ProxyEndpoints Eine Liste der ProxyEndpoints im Verzeichnis /proxies dieses API-Proxys. Dieses Element wird normalerweise nur angezeigt, wenn der API-Proxy mit der Edge-Verwaltungs-UI erstellt wurde. Dies ist einfach eine Manifest-Einstellung, die Einblick in den Inhalt des API-Proxys bietet. Nein
Resources Eine Liste der Ressourcen (JavaScript, Python, Java, XP) im Verzeichnis /resources dieses API-Proxys. Dieses Element wird normalerweise nur angezeigt, wenn der API-Proxy mit der Edge-Verwaltungs-UI erstellt wurde. Dies ist einfach eine Manifest-Einstellung, die Einblick in den Inhalt des API-Proxys bietet. Nein
Spec Gibt die OpenAPI-Spezifikation an, die dem API-Proxy zugeordnet ist. Der Wert wird auf eine URL oder einen Pfad im Spezifikationspeicher festgelegt.

Hinweis: Der Spezifikationsspeicher ist nur in der New Edge-Umgebung verfügbar. Weitere Informationen zum Spezifikationsspeicher finden Sie unter Spezifikationen verwalten und freigeben.
Nein
TargetServers Eine Liste von TargetServern, auf die in einem der TargetEndpoints dieses API-Proxys verwiesen wird. Normalerweise wird dieses Element nur angezeigt, wenn der API-Proxy mit der Edge-Verwaltungs-UI erstellt wurde. Dies ist einfach eine Manifest-Einstellung, die Einblick in den Inhalt des API-Proxys bietet. Nein
TargetEndpoints Eine Liste von TargetEndpoints im Verzeichnis /targets dieses API-Proxys. Dieses Element wird normalerweise nur angezeigt, wenn der API-Proxy mit der Edge-Verwaltungs-UI erstellt wurde. Dies ist einfach eine Manifest-Einstellung, die Einblick in den Inhalt des API-Proxys bietet. Nein

ProxyEndpoint

Die folgende Abbildung zeigt den Ablauf von Anfrage/Antwort:

Zeigt einen Client, der einen HTTP-Dienst aufruft. Die Anfrage durchläuft den Proxyendpunkt und dann den Zielendpunkt, bevor sie vom HTTP-Dienst verarbeitet wird. Die Antwort durchläuft den Zielendpunkt und dann den Proxyendpunkt, bevor sie an den Client zurückgegeben wird.

/apiproxy/proxies/default.xml

Die ProxyEndpoint-Konfiguration definiert die eingehende (Client-bezogene) Schnittstelle für einen API-Proxy. Wenn Sie einen ProxyEndpoint konfigurieren, richten Sie eine Netzwerkkonfiguration ein, die definiert, wie Clientanwendungen ('Apps') die Proxy-API aufrufen.

Die folgende ProxyEndpoint-Konfiguration würde unter /apiproxy/proxies gespeichert werden:

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <VirtualHost>default</VirtualHost>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

Folgende Konfigurationselemente sind in einem einfachen ProxyEndpoint erforderlich:

ProxyEndpoint-Konfigurationselemente

Name Beschreibung Standard Erforderlich?
ProxyEndpoint
name Der Name des ProxyEndpoints. Muss innerhalb der API-Proxykonfiguration eindeutig sein, wenn (in seltenen Fällen) mehrere ProxyEndpoints definiert sind. Die Zeichen, die Sie im Namen verwenden dürfen, sind auf folgende Zeichen beschränkt: A-Za-z0-9._\-$ % Ja
PreFlow Definiert die Richtlinien im PreFlow-Ablauf einer Anfrage oder Antwort. Ja
Flows
Definiert die Richtlinien in den bedingten Abläufen einer Anfrage oder Antwort.
Ja
PostFlow
Definiert die Richtlinien im PostFlow-Ablauf einer Anfrage oder Antwort.
Ja
HTTPProxyConnection Definiert die mit dem API-Proxy verknüpfte Netzwerkadresse und den URI-Pfad
BasePath

Ein erforderlicher String, der den URI-Pfad eindeutig identifiziert, der von Apigee Edge zum Weiterleiten eingehender Nachrichten an den richtigen API-Proxy verwendet wird.

Der BasePath ist ein URI-Fragment (z. B. /weather), das an die Basis-URL eines API-Proxys angehängt wird (z. B. http://apifactory-test.apigee.net). BasePath muss innerhalb einer Umgebung eindeutig sein. Die Eindeutigkeit wird überprüft, wenn ein API-Proxy generiert oder importiert wird.

Platzhalter in Basispfaden verwenden

Sie können in den API-Proxy-Basispfaden einen oder mehrere "*" verwenden. Mit dem Basispfad /team/*/members können Clients beispielsweise https://[host]/team/blue/members und https://[host]/team/green/members aufrufen, ohne neue API-Proxys für die Unterstützung neuer Teams erstellen zu müssen. Beachten Sie, dass /**/ nicht unterstützt wird.

Wichtig: Apigee unterstützt NICHT die Verwendung eines Platzhalters "*"* als erstes Element eines Basispfads. Dies wird beispielsweise NICHT unterstützt: /*/search. Das Starten des Basispfads mit einem „*“ kann aufgrund der Art und Weise, wie Edge gültige Pfade identifiziert, zu unerwarteten Fehlern führen.

/ Ja
VirtualHost

Verknüpft einen API-Proxy mit bestimmten Basis-URLs für eine Umgebung. Ein VirtualHost ist eine benannte Konfiguration, die eine oder mehrere URLs für eine Umgebung definiert.

Die benannten VirtualHosts, die für einen ProxyEndpoint definiert sind, bestimmen die Domains und Ports, über die ein API-Proxy verfügbar gemacht wird, und danach die URL, die Anwendungen zum Aufrufen eines API-Proxys verwenden.

Standardmäßig sind zwei benannte VirtualHosts für eine Umgebung definiert: default und secure. Eine Organisation kann auch benutzerdefinierte Domains definieren. Wenn Sie dafür sorgen möchten, dass ein API-Proxy nur über HTTPS verfügbar ist, legen Sie beispielsweise den VirtualHost in HTTPProxyConnection auf secure fest.

Standardeinstellung Nein
Properties Eine Reihe optionaler HTTP-Konfigurationseinstellungen kann als Attribute einer <ProxyEndpoint> definiert werden. Nein
FaultRules
Definiert, wie der ProxyEndpoint auf einen Fehler reagiert. Eine Fehlerregel gibt zwei Elemente an:
  • Eine Bedingung, die den Fehler angibt, der auf Grundlage der vordefinierten Kategorie, Unterkategorie oder Name des Fehlers verarbeitet werden soll
  • Eine oder mehrere Richtlinien, die das Verhalten der Fehlerregel für die entsprechende Bedingung definieren

Siehe Umgang mit Fehlern.

Nein
DefaultFaultRule

Behandelt alle Fehler (System, Transport, Messaging oder Richtlinie), die nicht explizit von einer anderen Fehlerregel behandelt werden.

Siehe Umgang mit Fehlern.

Nein
RouteRule Definiert das Ziel eingehender Anfragenachrichten nach der Verarbeitung durch die ProxyEndpoint-Anfragepipeline. Normalerweise verweist die RouteRule auf eine benannte TargetEndpoint-Konfiguration, kann aber auch direkt auf eine URL verweisen.
Name Erforderliches Attribut mit einem Namen für die RouteRule. Die Zeichen, die Sie im Namen verwenden dürfen, sind auf folgende Zeichen beschränkt: A-Za-z0-9._\-$ % Beispielsweise ist Cat2 %_ ein gültiger Name. Ja
Condition Eine optionale Bedingung, die zur dynamischen Weiterleitung zur Laufzeit verwendet wird. Bedingte Routingregeln sind beispielsweise nützlich, um ein inhaltsbasiertes Routing zu aktivieren, um die Back-End-Versionierung zu unterstützen. Nein
TargetEndpoint

Ein optionaler String, der eine benannte TargetEndpoint-Konfiguration identifiziert. Ein benannter TargetEndpoint ist ein beliebiger TargetEndpoint, der im selben API-Proxy im Verzeichnis /targets definiert ist.

Wenn Sie einen TargetEndpoint benennen, geben Sie an, wohin Anfragenachrichten nach der Verarbeitung durch die ProxyEndpoint-Anforderungspipeline weitergeleitet werden sollen. Dies ist eine optionale Einstellung.

Ein ProxyEndpoint kann eine URL direkt aufrufen. Zum Beispiel kann eine JavaScript- oder Java-Ressource, die in der Rolle eines HTTP-Clients arbeitet, die grundlegende Duft eines TargetEndpoint ausführen, bei dem Anfragen an einen Back-End-Dienst weitergeleitet werden.

Nein
URL Ein optionaler String, der eine vom ProxyEndpoint aufgerufene ausgehende Netzwerkadresse definiert und alle TargetEndpoint-Konfigurationen umgeht, die möglicherweise unter /targets gespeichert sind Nein

So konfigurieren Sie RouteRules

Ein benannter TargetEndpoint bezieht sich auf eine Konfigurationsdatei unter /apiproxy/targets, an die RouteRule eine Anfrage nach der Verarbeitung durch den ProxyEndpoint weiterleitet.

Die folgende RouteRule bezieht sich beispielsweise auf die Konfiguration /apiproxy/targets/myTarget.xml:

<RouteRule name="default">
  <TargetEndpoint>myTarget</TargetEndpoint>
</RouteRule>

Direkter URL-Aufruf

Ein ProxyEndpoint kann auch direkt einen Back-End-Dienst aufrufen. Bei dem direkten URL-Aufruf werden alle benannten TargetEndpoints-Konfigurationen unter /apiproxy/targets umgangen. Aus diesem Grund ist TargetEndpoint eine optionale API-Proxykonfiguration, obwohl in der Praxis kein direkter Aufruf vom ProxyEndpoint empfohlen wird.

Die folgende RouteRule führt beispielsweise einen HTTP-Aufruf an http://api.mycompany.com/v2 aus.

<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL> 
</RouteRule>

Bedingte Routen

RouteRules können für die Unterstützung von dynamischem Routing zur Laufzeit verkettet werden. Eingehende Anfragen können an benannte TargetEndpoint-Konfigurationen, direkt an URLs oder eine Kombination aus beidem weitergeleitet werden, basierend auf HTTP-Headern, Nachrichteninhalten, Suchparametern oder Kontextinformationen wie Tageszeit, Gebietsschema usw.

Bedingte RouteRules funktionieren wie andere bedingte Anweisungen in Apigee Edge. Siehe Bedingungsreferenz und Variablenreferenz.

Die folgende RouteRule-Kombination wertet beispielsweise zuerst die eingehende Anfrage aus, um den Wert eines HTTP-Headers zu prüfen. Wenn der HTTP-Header routeTo den Wert TargetEndpoint1 hat, wird die Anfrage an den TargetEndpoint mit dem Namen TargetEndpoint1 weitergeleitet. Ist dies nicht der Fall, wird die eingehende Anfrage an http://api.mycompany.com/v2 weitergeleitet.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

Nullrouten

Eine Null-RouteRule kann so definiert werden, dass sie Supportszenarien unterstützt, in denen die Anfragenachricht nicht an den TargetEndpoint weitergeleitet werden muss. Dies ist nützlich, wenn der ProxyEndpoint die gesamte Verarbeitung übernimmt, z. B. indem JavaScript verwendet wird, um einen externen Dienst aufzurufen, oder Daten aus einer Suche in den Schlüssel/Wert-Speicher der API-Dienste abzurufen.

Im Folgenden wird beispielsweise eine Nullroute definiert:

<RouteRule name="GoNowhere"/>

Bedingte Nullrouten können nützlich sein. Im folgenden Beispiel wird eine Nullroute konfiguriert, die ausgeführt wird, wenn ein HTTP-Header request.header.X-DoNothing einen anderen Wert als null hat.

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

Denken Sie daran, dass die Routingregeln verkettet werden können. Eine bedingte Nullroute wäre also normalerweise eine Komponente eines Satzes von Routingregeln, die für ein bedingtes Routing geeignet sind.

Eine praktische Verwendung einer bedingten Nullroute würde das Caching unterstützen. Mithilfe des Werts der Variablen, der durch die Cache-Richtlinie festgelegt wird, können Sie einen API-Proxy so konfigurieren, dass die Nullroute ausgeführt wird, wenn ein Eintrag aus dem Cache bereitgestellt wird.

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

TargetEndpoint

Zeigt einen Client, der einen HTTP-Dienst aufruft. Die Anfrage durchläuft den Proxyendpunkt und dann den Zielendpunkt, bevor sie vom HTTP-Dienst verarbeitet wird. Die Antwort durchläuft den Zielendpunkt und dann den Proxyendpunkt, bevor sie an den Client zurückgegeben wird.

Ein TargetEndpoint ist die ausgehende Entsprechung eines ProxyEndpoints. Ein TargetEndpoint fungiert als Client für einen Back-End-Dienst oder eine API. Er sendet Anfragen und empfängt Antworten.

Ein API-Proxy benötigt keine TargetEndpoints. ProxyEndpoints können so konfiguriert werden, dass URLs direkt aufgerufen werden. Ein API-Proxy ohne TargetEndpoints enthält in der Regel einen ProxyEndpoint, der entweder einen Back-End-Dienst direkt aufruft oder einen Dienst konfiguriert, der Java oder JavaScript verwendet.

TargetEndpoint-Konfiguration

/targets/default.xml

Der TargetEndpoint definiert die ausgehende Verbindung von Apigee Edge zu einem anderen Dienst oder einer anderen Ressource.

Hier ein Beispiel für eine TargetEndpoint-Konfiguration:

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

TargetEndpoint-Konfigurationselemente

Ein TargetEndpoint kann ein Ziel auf eine der folgenden Arten aufrufen:

  • HTTPTargetConnection für HTTP(S)-Aufrufe
  • LocalTargetConnection für die lokale Proxy-zu-Proxy-Verkettung
  • ScriptTarget für Aufrufe eines Edge-gehosteten Node.js-Skripts

Konfigurieren Sie nur eines davon in einem TargetEndpoint.

Name Beschreibung Standard Erforderlich?
TargetEndpoint
name Der Name des TargetEndpoint, der innerhalb der API-Proxykonfiguration eindeutig sein muss. Der Name des TargetEndPoint wird in der ProxyEndpoint RouteRule verwendet, um Anfragen für die ausgehende Verarbeitung zu leiten. Die Zeichen, die Sie im Namen verwenden dürfen, sind auf folgende Zeichen beschränkt: A-Za-z0-9._\-$ % Ja
PreFlow Definiert die Richtlinien im PreFlow-Ablauf einer Anfrage oder Antwort. Ja
Flows
Definiert die Richtlinien in den bedingten Abläufen einer Anfrage oder Antwort.
Ja
PostFlow
Definiert die Richtlinien im PostFlow-Ablauf einer Anfrage oder Antwort.
Ja
HTTPTargetConnection

Gibt mit seinen untergeordneten Elementen die Reichweite einer Back-End-Ressource über HTTP an.

Wenn Sie HTTPTargetConnection verwenden, sollten Sie keine anderen Arten von Zielverbindungen (ScriptTarget oder LocalTargetConnection) konfigurieren.

URL Definiert die Netzwerkadresse des Back-End-Dienstes, an den der TargetEndpoint Anfragenachrichten weiterleitet. Nein
LoadBalancer

Definiert eine oder mehrere benannte TargetServer-Konfigurationen. Benannte TargetServer-Konfigurationen können für das Load-Balancing verwendet werden, um zwei oder mehr Endpunktkonfigurationsverbindungen zu definieren.

Sie können TargetServers auch verwenden, um API-Proxykonfigurationen aus konkreten Back-End-Dienst-Endpunkt-URLs zu entkoppeln.

Siehe Load-Balancing über Back-End-Server.

Nein
Properties Eine Reihe optionaler HTTP-Konfigurationseinstellungen kann als Attribute einer <TargetEndpoint> definiert werden. Nein
SSLInfo Definieren Sie optional TLS/SSL-Einstellungen für einen TargetEndpoint, um die TLS/SSL-Verbindung zwischen dem API-Proxy und dem Zieldienst zu steuern. Siehe TLS/SSL TargetEndpoint-Konfiguration. Nein
LocalTargetConnection Mit seinen untergeordneten Elementen definiert er eine Ressource, die lokal erreicht werden soll, und umgeht Netzwerkmerkmale wie Load-Balancing und Nachrichtenprozessoren.

Zum Angeben der Zielressource fügen Sie entweder das untergeordnete APIProxy-Element (mit dem ProxyEndpoint-Element) oder das untergeordnete Element Pfad hinzu.

Weitere Informationen finden Sie unter API-Proxys zusammenhalten.

Wenn Sie LocalTargetConnection verwenden, konfigurieren Sie keine anderen Arten von Zielverbindungen (HTTPTargetConnection oder ScriptTarget).

APIProxy Gibt den Namen eines API-Proxys an, der als Ziel für Anfragen verwendet werden soll. Der Zielproxy muss sich in derselben Organisation und Umgebung befinden wie der Proxy, der Anfragen sendet. Das bietet eine Alternative zum Pfadelement. Nein
ProxyEndpoint Wird mit APIProxy verwendet, um den Namen des ProxyEndpoint des Zielproxys anzugeben. Nein
Path Gibt den Endpunktpfad eines API-Proxys an, der als Ziel für Anfragen verwendet werden soll. Der Zielproxy muss sich in derselben Organisation und Umgebung befinden wie der Proxy, der Anfragen sendet. Dies ist eine Alternative zur Verwendung von APIProxy. Nein
FaultRules
Definiert, wie der TargetEndpoint auf einen Fehler reagiert. Eine Fehlerregel gibt zwei Elemente an:
  • Eine Bedingung, die den Fehler angibt, der auf Grundlage der vordefinierten Kategorie, Unterkategorie oder Name des Fehlers verarbeitet werden soll
  • Eine oder mehrere Richtlinien, die das Verhalten der Fehlerregel für die entsprechende Bedingung definieren

Siehe Umgang mit Fehlern.

Nein
DefaultFaultRule

Behandelt alle Fehler (System, Transport, Messaging oder Richtlinie), die nicht explizit von einer anderen FaultRule behandelt werden.

Siehe Umgang mit Fehlern.

Nein
ScriptTarget
ResourceURL

Definiert den Ressourcentyp (Knoten) und den Namen des Node.js-Hauptskripts, das die TargetEndpoint-Funktion implementiert.

<ResourceURL>node://server.js</ResourceURL>

Das Skript muss in die Ressourcendateien Ihres API-Proxys aufgenommen werden. Siehe Node.js zu einem vorhandenen API-Proxy hinzufügen.

Wenn Sie ScriptTarget verwenden, konfigurieren Sie keine anderen Arten von Zielverbindungen (HTTPTargetConnection oder LocalTargetConnection).

Ja
EnvironmentVariable

Optional können Sie Umgebungsvariablen an das Node.js-Hauptskript übergeben.

Siehe Edge-Unterstützung für Node.js-Module.

Nein
Arguments

Optional können Sie Argumente an das Node.js-Hauptskript übergeben.

Siehe Edge-Unterstützung für Node.js-Module.

Nein

TLS/SSL-TargetEndpoint-Konfiguration

TargetEndpoints müssen häufig HTTPS-Verbindungen mit heterogenen Back-End-Infrastruktur verwalten. Aus diesem Grund werden verschiedene TLS/SSL-Konfigurationseinstellungen unterstützt.

TLS/SSL-Konfigurationselemente für TargetEndpoint

Name Beschreibung Standard Erforderlich?
SSLInfo
Enabled Gibt an, ob TLS/SSL für den Endpunkt aktiviert ist. Der Standardwert ist true, wenn <URL> das HTTPS-Protokoll angibt, und false, wenn <URL> HTTP angibt. true, wenn <URL> HTTPS angibt Nein
TrustStore Einen Schlüsselspeicher mit vertrauenswürdigen Serverzertifikaten. Nein
ClientAuthEnabled Eine Einstellung, die die ausgehende Clientauthentifizierung aktiviert (2 Wege von TLS/SSL) false Nein
KeyStore Einen Schlüsselspeicher, der private Schlüssel für die ausgehende Clientauthentifizierung verwendet Ja (wenn ClientAuthEnabled "true") ist
KeyAlias Der Schlüsselalias des privaten Schlüssels, der für die ausgehende Clientauthentifizierung verwendet wird Ja (wenn ClientAuthEnabled "true") ist
Ciphers

Unterstützte Chiffren für ausgehende TLS/SSL. Wenn keine Chiffren angegeben sind, sind alle für die JVM verfügbaren Chiffren erlaubt.

Fügen Sie die folgenden Elemente hinzu, um die Chiffren einzuschränken:

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>    
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>
Nein
Protocols

Unterstützte Protokolle für ausgehendes TLS/SSL. Wenn keine Protokolle angegeben sind, sind alle für die JVM verfügbaren Protokolle zulässig.

Fügen Sie die folgenden Elemente hinzu, um die unterstützten Protokolle aufzulisten:

<Protocols>
 <Protocol>TLSv1.1</Protocol>
 <Protocol>TLSv1.2</Protocol>
</Protocols>
Nein
CommonName

Falls angegeben, ein Wert, anhand dessen der Common Name des Zielzertifikats validiert wird. Dieser Wert gilt nur für TargetEndpoint- und TargetServer-Konfigurationen. Er gilt nicht für VirtualHost-Konfigurationen.

Standardmäßig wird der angegebene Wert exakt mit dem allgemeinen Namen des Zielzertifikats abgeglichen. Wenn Sie beispielsweise *.myhost.com als Wert für <CommonName> verwenden, wird der Ziel-Hostname nur dann abgeglichen und validiert, wenn der genaue Wert *.myhost.com als allgemeinen Namen im Zielzertifikat angegeben ist.

Optional kann Apigee den Abgleich mit Platzhaltern mithilfe des Attributs wildcardMatch durchführen.

Beispielsweise wird ein allgemeiner Name, der in einem Zielzertifikat als abc.myhost.com angegeben ist, abgeglichen und validiert, wenn das Element <CommonName> so angegeben wird:

<CommonName wildcardMatch="true">*.myhost.com</CommonName>

Nein

Beispiel für TargetEndpoint mit aktivierter ausgehender Clientauthentifizierung

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

Eine ausführliche Anleitung finden Sie unter TLS von Edge zum Back-End (Cloud und Private Cloud) konfigurieren.

Ablaufvariablen zum dynamischen Festlegen von TLS/SSL-Werten verwenden

Sie können auch TLS/SSL-Details dynamisch festlegen, um flexible Laufzeitanforderungen zu unterstützen. Wenn Ihr Proxy zum Beispiel mit zwei möglichen Zielen verbunden ist (ein Testziel und ein Produktionsziel), können Sie dafür sorgen, dass Ihr API-Proxy programmatisch ermittelt, welche Umgebung aufgerufen wird, und Verweise dynamisch auf den entsprechenden Schlüsselspeicher und Truststore festlegen. Im folgenden Artikel der Apigee-Community wird dieses Szenario ausführlich erläutert und es werden Beispiele für ausführbare API-Proxys bereitgestellt: https://community.apigee.com/articles/21424/dynamic-sslinfo-for-targetendpoint-using-variable.html.

Im folgenden Beispiel wird gezeigt, wie das Tag <SSLInfo> in einer TargetEndpoint-Konfiguration festgelegt werden. Die Werte können zur Laufzeit bereitgestellt werden, beispielsweise über die Richtlinien "Java-Callout", "JavaScript" oder "Assign Message". Verwenden Sie die Nachrichtenvariablen, die die Werte enthalten, die Sie festlegen möchten.

Variablen sind nur in folgenden Elementen zulässig.

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

Referenzen verwenden, um TLS/SSL-Werte dynamisch festzulegen

Wenn Sie einen TargetEndpoint konfigurieren, der HTTPS verwendet, müssen Sie berücksichtigen, dass das TLS/SSL-Zertifikat abläuft oder eine Änderung der Systemkonfiguration eine Aktualisierung des Zertifikats erfordert. Wenn Sie in einer Edge for Private Cloud-Installation TLS/SSL mithilfe statischer Werte oder mithilfe von Flussvariablen konfigurieren, müssen Sie möglicherweise die Message Processors neu starten.

Weitere Informationen finden Sie unter TLS-Zertifikat aktualisieren.

Sie können den TargetEndpoint jedoch optional so konfigurieren, dass er einen Verweis auf den Keystore oder Truststore verwendet. Der Vorteil einer Referenz besteht darin, dass Sie die Referenz aktualisieren können, um auf einen anderen Keystore oder Truststore zu verweisen, um das TLS/SSL-Zertifikat zu aktualisieren, ohne die Nachrichtenprozessoren neu starten zu müssen.

Im Folgenden sehen Sie ein Beispiel für einen TargetEndpoint, der einen Verweis auf den Schlüsselspeicher verwendet:

<SSLInfo> 
    <Enabled>true</Enabled> 
    <ClientAuthEnabled>false</ClientAuthEnabled> 
    <KeyStore>ref://keystoreref</KeyStore> 
    <KeyAlias>myKeyAlias</KeyAlias> 
</SSLInfo>

Verwenden Sie den folgenden POST-API-Aufruf, um die Referenz mit dem Namen keystoreref zu erstellen:

curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
-d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

Die Referenz gibt den Namen des Schlüsselspeichers und seinen Typ an.

Verwenden Sie den folgenden GET API-Aufruf, um die Referenz aufzurufen:

curl -X GET https://api.enterprise.apigee.com/v1/o/[org_name}/e/{env_name}/references/keystoreref -u uname:password

Verwenden Sie den folgenden PUT-Aufruf, um später die Referenz so zu ändern, dass sie auf einen anderen Schlüsselspeicher verweist, damit der Alias denselben Namen hat:

curl -X PUT -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references/keystoreref \
-d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

TargetEndpoint mit Ziel-Load-Balancing

TargetEndpoints unterstützt Load-Balancing über mehrere benannte TargetServer mit drei Load-Balancing-Algorithmen.

Eine ausführliche Anleitung finden Sie unter Load-Balancing über Back-End-Server.

Richtlinien

Das Verzeichnis /policies in einem API-Proxy enthält alle Richtlinien, die an Abläufe im API-Proxy angehängt werden können.

Richtlinienkonfigurationselemente

Name Beschreibung Standard Erforderlich?
Policy
name

Der interne Name der Richtlinie. Folgende Zeichen sind im Namen zulässig: A-Za-z0-9._\-$ %. Die Edge-Verwaltungs-UI erzwingt jedoch zusätzliche Einschränkungen, z. B. das automatische Entfernen nicht alphanumerischer Zeichen.

Optional können Sie das Element <DisplayName> verwenden, um der Richtlinie im Proxy-Editor der Verwaltungs-UI einen anderen Namen in natürlicher Sprache zu geben.

Ja
enabled

Setzen Sie den Wert auf true, um die Richtlinie zu erzwingen.

Setzen Sie den Wert auf false, um die Richtlinie zu "deaktivieren". Die Richtlinie wird nicht erzwungen, selbst wenn sie mit einem Ablauf verknüpft ist.

true Nein
continueOnError

Legen Sie false fest, um einen Fehler zurückzugeben, wenn eine Richtlinie fehlschlägt. Dies ist für die meisten Richtlinien zu erwarten.

Legen Sie true fest, damit die Ablaufausführung auch nach dem Fehlschlagen einer Richtlinie fortgesetzt wird.

false Nein
async

Hinweis: Dieses Attribut bewirkt nicht, dass die Richtlinie asynchron ausgeführt wird. In den meisten Fällen sollten Sie den Standardwert false beibehalten.

Wenn dieser Wert auf true gesetzt ist, wird die Richtlinienausführung auf einen anderen Thread übertragen, sodass der Hauptthread weitere Anfragen verarbeiten kann. Wenn die Offline-Verarbeitung abgeschlossen ist, wird der Hauptthread zurückgegeben und die Verarbeitung des Nachrichtenablaufs abgeschlossen. In einigen Fällen verbessert die Einstellung von asynchron auf true die API-Proxy-Leistung. Eine übermäßige Verwendung kann jedoch die Leistung beeinträchtigen, wenn zu viele Thread-Switches erzeugt wird.

Informationen zur Verwendung des asynchronen Verhaltens in API-Proxys finden Sie unter JavaScript-Objektmodell.

false Nein

Richtlinienbindung

Die folgende Abbildung zeigt die Ausführungssequenz der API-Proxys:

zeigt einen Client, der einen HTTP-Dienst aufruft. Die Anfrage geht an den ProxyEndpoint und TargetEndpoint, die jeweils Schritte enthalten, die Richtlinien auslösen. Nachdem der HTTP-Dienst die Antwort zurückgegeben hat, wird die Antwort vom TargetEndpoint verarbeitet. Anschließend wird das ProxyEndoping zurückgegeben, bevor an den Client zurückgegeben wird. Wie bei der Anfrage wird die Antwort von Richtlinien in Schritten verarbeitet.

Wie oben gezeigt:

Richtlinien werden als Verarbeitungsschritte an Abläufe angehängt. Mit dem Namen der Richtlinie wird auf die Richtlinie verwiesen, die als Verarbeitungsschritt erzwungen werden soll. Richtlinienanhänge haben folgendes Format:

<Step><Name>MyPolicy</Name></Step>

Richtlinien werden in der Reihenfolge erzwungen, in der sie einem Ablauf zugeordnet sind. Beispiel:

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

Konfigurationselemente der Richtlinienanhänge

Name Beschreibung Standard Erforderlich?
Step
Name Der Name der Richtlinie, die von dieser Schrittdefinition ausgeführt werden soll. Ja
Condition Eine bedingte Anweisung, die bestimmt, ob die Richtlinie erzwungen wird. Wenn eine Richtlinie mit einer Bedingung verknüpft ist, wird die Richtlinie nur ausgeführt, wenn die Anweisung der Bedingung als "true" ausgewertet wird. Nein

Abläufe

ProxyEndpoint und TargetEndpoint definieren eine Pipeline für die Verarbeitung von Anfragen und Antworten. Eine Verarbeitungspipeline besteht aus einem Anfrageablauf und einem Antwortablauf. Jeder Anfrageablauf und Antwortablauf ist in einen PreFlow, einen oder mehrere optionale "Conditional"- oder "named"-Abläufe sowie in einen PostFlow unterteilt.

  • PreFlow: Wird immer ausgeführt. Wird vor allen bedingten Abläufen ausgeführt.
  • PostFlow: Wird immer ausgeführt. Wird nach allen bedingten Abläufen ausgeführt.

Sie können dem ProxyEndpoint auch einen PostClientFlow hinzufügen, der ausgeführt wird, nachdem die Antwort an die anfragende Clientanwendung zurückgegeben wird. An diesen Ablauf können nur die MessageLogging-Richtlinie und die Google Stackdriver Logging-Erweiterung angehängt werden. PostClientFlow reduziert die Latenz des API-Proxys und stellt Informationen für Logging zur Verfügung, die erst berechnet werden, wenn die Antwort an den Client zurückgegeben wurde, z. B. client.sent.start.timestamp und client.sent.end.timestamp. Der Ablauf wird hauptsächlich für die Messung des Zeitintervalls zwischen dem Start- und Endzeitstempel der Antwortnachricht verwendet.

Kurzes Anleitungsvideo ansehen

Video: Sehen Sie sich dieses kurze Video zur Verwendung eines Nachrichten-Loggings in PostClientFlow an.

Hier ein Beispiel für einen PostClientFlow mit angehängter Nachrichten-Logging-Richtlinie:

    ...
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <PostClientFlow>
        <Request/>
        <Response>
            <Step>
                <Name>Message-Logging-1</Name>
            </Step>
        </Response>
    </PostClientFlow>
    ...

Die API-Proxy-Verarbeitungspipeline führt Flows in der folgenden Sequenz aus:

Anfrage-Pipeline:

  1. Proxyanfrage-PreFlow
  2. Proxyanfrage für bedingte Abläufe (optional)
  3. Proxyanfrage PostFlow
  4. Zielanfrage PreFlow
  5. Zielanfrage für bedingte Abläufe (optional)
  6. Zielanfrage PostFlow

Antwort-Pipeline:

  1. Zielantwort PreFlow
  2. Zielantwort für bedingte Abläufe (optional)
  3. Zielantwort PostFlow
  4. Proxyantwort PreFlow
  5. Proxyantwort für bedingte Abläufe (optional)
  6. Proxyantwort PostFlow
  7. PostClientFlow-Antwort (optional)

Nur Abläufe mit Richtlinienanhängen müssen in ProxyEndpoint- oder TargetEndpoint-Konfigurationen konfiguriert werden. PreFlow und PostFlow müssen nur in einer ProxyEndpoint- oder TargetEndpoint-Konfiguration angegeben werden, wenn eine Richtlinie während der PreFlow- oder PostFlow-Verarbeitung erzwungen werden muss.

Im Gegensatz zu bedingten Abläufen ist die Reihenfolge von PreFlow- und PostFlow-Elementen nicht wichtig. Der API-Proxy wird immer an der entsprechenden Stelle in der Pipeline ausgeführt, unabhängig davon, wo sie in der Endpunktkonfiguration angezeigt werden.

Bedingte Abläufe

ProxyEndpoints und TargetEndpoints unterstützen eine unbegrenzte Anzahl bedingter Abläufe (auch als "benannte Abläufe" bezeichnet).

Der API-Proxy testet die im bedingten Ablauf angegebene Bedingung. Wenn die Bedingung erfüllt wird, werden die Verarbeitungsschritte im bedingten Ablauf vom API-Proxy ausgeführt. Wird die Bedingung nicht erfüllt, werden die Verarbeitungsschritte im bedingten Ablauf umgangen. Bedingte Abläufe werden in der im API-Proxy definierten Reihenfolge ausgewertet und der erste, dessen Bedingung erfüllt ist, wird ausgeführt.

Durch die Definition bedingter Abläufe können Sie die Verarbeitungsschritte in einem API-Proxy basierend auf Folgendem anwenden:

  • Anfrage-URI
  • HTTP-Verb (GET/PUT/POST/DELETE)
  • Wert eines Abfrageparameters, Headers und Formularparameters
  • Viele andere Bedingungstypen

Der folgende bedingte Ablauf gibt beispielsweise an, dass er nur ausgeführt wird, wenn der Anfrageressourcenpfad /accesstoken ist. Jede eingehende Anfrage mit dem Pfad /accesstoken führt dazu, dass dieser Ablauf zusammen mit allen Richtlinien ausgeführt wird, die an den Ablauf angehängt sind. Wenn der Anfragepfad nicht das Suffix /accesstoken enthält, wird der Ablauf nicht ausgeführt (obwohl ein anderer bedingter Ablauf möglich ist).

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request> 
  </Flow>
</Flows>   

Elemente der Ablaufkonfiguration

Name Beschreibung Standard Erforderlich?
Flow Eine Anfrage oder eine Antwortverarbeitungspipeline, die von einem ProxyEndpoint oder TargetEndpoint definiert wird
Name Der eindeutige Name des Ablaufs. Ja
Condition Eine bedingte Anweisung, die eine oder mehrere Variablen auswertet, die als true oder false ausgewertet werden. Alle Abläufe mit Ausnahme der vordefinierten PreFlow- und PostFlow-Typen müssen eine Bedingung für ihre Ausführung definieren. Ja
Request Die mit der Verarbeitung von Anfragenachrichten verknüpfte Pipeline Nein
Response Die Pipeline, die mit der Verarbeitung von Antwortnachrichten verknüpft ist Nein

Schrittverarbeitung

Die sequentielle Reihenfolge bedingter Flows wird von Apigee Edge erzwungen. Bedingte Abläufe werden von oben nach unten ausgeführt. Der erste bedingte Ablauf, dessen Bedingung true erfüllt, wird ausgeführt und nur ein bedingter Ablauf wird ausgeführt.

Beispiel: In der folgenden Ablaufkonfiguration führt jede eingehende Anfrage, die nicht das Pfadsuffix /first oder /second enthält, ThirdFlow aus. Dabei wird die Richtlinie Return404 ausgeführt.

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

Ressourcen

"Ressourcen" (Ressourcendateien zur Verwendung in API-Proxys) sind Skripts, Code und XSL-Transformationen, die Abläufen mithilfe von Richtlinien hinzugefügt werden können. Diese werden im Bereich „Scripts“ des API-Proxy-Editors in der Verwaltungsoberfläche angezeigt.

Die unterstützten Ressourcentypen finden Sie unter Ressourcendateien.

Ressourcen können in einem API-Proxy, in einer Umgebung oder in einer Organisation gespeichert werden. In jedem Fall wird in einer Richtlinie mit dem Namen auf eine Ressource verwiesen. API-Dienste auflösen den Namen, indem sie vom API-Proxy in die Umgebung oder Organisationsebene wechseln.

Eine auf Organisationsebene gespeicherte Ressource kann über Richtlinien in jeder Umgebung referenziert werden. Eine auf der Umgebungsebene gespeicherte Ressource kann von den Richtlinien in dieser Umgebung referenziert werden. Eine auf API-Proxyebene gespeicherte Ressource kann nur von Richtlinien in diesem API-Proxy referenziert werden.