Routing-Regeln zum Verbinden von API-Stufen mit einem benutzerdefinierten Domainnamen für REST APIs - Amazon API Gateway

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Routing-Regeln zum Verbinden von API-Stufen mit einem benutzerdefinierten Domainnamen für REST APIs

Eine Routing-Regel besteht aus einer Reihe von Bedingungen, bei deren Erfüllung eine Aktion ausgelöst wird. Eine Regel kann beispielsweise jede eingehende Anfrage, die an einen benutzerdefinierten Domainnamen gerichtet ist und den Header Hello:World sowie den Basispfad users enthält, an die production-Stufe einer REST-API weiterleiten.

Regeln werden in der Reihenfolge ihrer Priorität ausgewertet. Wenn Sie den Routing-Modus ROUTING_RULE_THEN_API_MAPPING verwenden, wertet API Gateway stets zuerst alle Routing-Regeln aus, bevor API-Zuweisungen geprüft werden. Die folgende Liste beschreibt, wie eine Routing-Regel Bedingungen, Aktionen und Prioritäten verwendet.

Bedingungen

Wenn die Bedingungen für eine Regel erfüllt sind, wird die dazugehörige Aktion durchgeführt. API Gateway unterstützt bis zu zwei Header-Bedingungen und eine Pfadbedingung. API Gateway wertet Header-Bedingungen und Basispfadbedingungen zusammen aus.

Sie können eine Regel auch ohne Bedingungen erstellen. Wenn API Gateway diese Regel auswertet, wird die Aktion immer ausgeführt. Eine Regel ohne Bedingungen kann als Catch-all-Regel verwendet werden.

Weitere Informationen über Header-Bedingungen finden Sie unter Abgleichen der Header-Bedingungen. Weitere Informationen über Pfadbedingungen finden Sie unter Basispfadbedingungen anpassen.

Aktionen

Aktionen sind das Ergebnis der Übereinstimmung von Bedingungen mit einer Routing-Regel. Derzeit wird nur das Aufrufen einer Stufe einer REST-API unterstützt.

Jede Regel kann eine Aktion haben.

Priorität

Die Priorität bestimmt die Reihenfolge, in der Regeln ausgewertet werden, ausgehend vom niedrigsten Wert hin zum höchsten Wert. Zwei Regeln können nicht dieselbe Priorität haben.

Sie können die Priorität im Bereich 1–1.000.000 festlegen. Eine Regel mit der Priorität 1 wird von API Gateway zuerst ausgewertet. Wir empfehlen, beim Erstellen einer Regel Lücken zwischen den Prioritäten zu lassen. So können Sie die Reihenfolge später leichter ändern oder neue Regeln hinzufügen. Weitere Informationen finden Sie unter Ändern der Priorität einer Routing-Regel.

Beispiele dafür, wie API Gateway Routing-Regeln auswertet, finden Sie unter Beispiele dafür, wie API Gateway Routing-Regeln auswertet.

Bedingungstypen für Routing-Regeln in API Gateway

Im Folgenden werden die Bedingungstypen für Routing-Regeln beschrieben. API Gateway wendet eine Regel nur dann an, wenn alle Bedingungen erfüllt sind.

Abgleichen der Header-Bedingungen

Wenn Sie eine Header-Bedingung erstellen, können Sie den Header-Namen und den Header-Glob-Wert abgleichen, z. B. Hello:World. API Gateway verwendet für den Abgleich von Header-Bedingungen eine exakte Übereinstimmung. Ihre Bedingung kann bis zu zwei Header mit AND zwischen ihnen verwenden. Eine Bedingung kann also z. B. dann übereinstimmen, wenn eine eingehende Anfrage sowohl Hello:World als auch x-version:beta enthält.

Bei der Übereinstimmung des Header-Namens wird die Groß-/Kleinschreibung nicht berücksichtigt, beim Header-Glob-Wert hingegen schon. Hello:World stimmt mit hello:World überein, jedoch nicht mit Hello:world.

Eine Liste der eingeschränkten Header-Werte finden Sie unter Einschränkungen.

Verwenden von Platzhaltern mit Header-Bedingungen

Platzhalter dürfen nur im Header-Glob-Wert verwendet werden. Zulässig sind dabei: *prefix-match, suffix-match* oder *contains*. Die folgende Tabelle zeigt Beispiele, wie Platzhalter für die Übereinstimmung mit Header-Bedingungen verwendet werden können.

Header-Bedingungen Anfragen, die der Routing-Regel entsprechen Anfragen, die nicht der Routing-Regel entsprechen

x-version: a*

  • x-version: account

  • x-version: alpha

  • x-version: backup

  • x-version: beta

  • x-version: users

x-version: *a

  • x-version: alpha

  • x-version: beta

  • x-version: account

  • x-version: backup

  • x-version: users

x-version: *a*

  • x-version: account

  • x-version: alpha

  • x-version: backup

  • x-version: beta

  • x-version: users

x-version: *a* und x-version: *b*

  • x-version: backup

  • x-version: beta

  • x-version: account

  • x-version: alpha

  • x-version: users

x-version: b* und x-version: *a

  • x-version: beta

  • x-version: account

  • x-version: alpha

  • x-version: backup

  • x-version: users

x-version: *

  • x-version: account

  • x-version: alpha

  • x-version: backup

  • x-version: beta

  • x-version: users

Keine

Wenn Sie Bedingungen für mehrere Header-Werte erstellen, wie z. B. Accept:application/json,text/xml, empfehlen wir, *contains* für Ihre Header-Bedingungen zu verwenden und keine Bedingungen mit dem Kommazeichen (,) zu erstellen.

Da API Gateway Header-Bedingungen wörtlich prüft, können semantisch gleiche Anfragen unterschiedlich weitergeleitet werden. Die folgende Tabelle zeigt die unterschiedlichen Ergebnisse der Routing-Regeln.

Header-Bedingungen Anfragen, die der Routing-Regel entsprechen Anfragen, die nicht der Routing-Regel entsprechen

Accept: *json

  • Accept:application/json Accept:text/xml

  • Accept:application/json,text/xml

Accept: *json*

  • Accept:application/json Accept:text/xml

  • Accept:application/json,text/xml

Keine

Basispfadbedingungen anpassen

Wenn Sie eine Basispfadbedingung erstellen und die eingehende Anfrage den von Ihnen angegebenen Pfad enthält, wird die Regel angewendet. Bei der Übereinstimmung wird die Groß- und Kleinschreibung berücksichtigt, daher stimmt der Pfad New/Users nicht mit new/users überein.

Sie können eine Basispfadbedingung nur für einen Basispfad erstellen.

Eine Liste der eingeschränkten Basispfadbedingungen finden Sie unter Einschränkungen.

Entfernen des Basispfads mit Basispfadbedingungen

Wenn Sie eine Basispfadbedingung erstellen, können Sie wählen, ob der Basispfad entfernt werden soll. Wenn Sie den Basispfad entfernen, löscht API Gateway den eingehenden übereinstimmenden Basispfad, wenn es die Ziel-API aufruft. Dieses Verhalten entspricht dem einer API-Zuweisung. Wenn Sie den Basispfad nicht entfernen, leitet API Gateway den gesamten Basispfad an die Ziel-API weiter. Wir empfehlen, den Basispfad nur dann zu entfernen, wenn Sie eine API-Zuweisung neu erstellen.

Die folgende Tabelle zeigt Beispiele dafür, wie API Gateway die Bedingung zum Entfernen des Basispfads auswertet.

Bedingung Leerzeichen des Basispfads entfernen Eingehende Anfragen Ergebnis

Wenn der Basispfad PetStoreShopper/dogs enthält

Wahr

GET https://example.com/PetStoreShopper/dogs

API Gateway ruft die GET-Methode der /-Ressource auf.

Wenn der Basispfad PetStoreShopper/dogs enthält

Falsch

GET https://example.com/PetStoreShopper/dogs

API Gateway ruft die GET-Methode der PetStoreShopper/dogs-Ressource auf.

Wenn der Basispfad PetStoreShopper enthält

Wahr

GET https://example.com/PetStoreShopper/dogs

API Gateway ruft die GET-Methode der dogs-Ressource auf.

Wenn der Basispfad PetStoreShopper enthält

Falsch

GET https://example.com/PetStoreShopper/dogs

API Gateway ruft die GET-Methode der PetStoreShopper/dogs-Ressource auf.

Wenn der Basispfad PetStoreShopper enthält

Wahr

GET https://example.com/PetStoreShopper?birds=available

API Gateway ruft die GET-Methode der /-Ressource mit dem Abfragezeichenfolgenparameter birds=available auf.

Wenn der Basispfad PetStoreShopper enthält

Falsch

GET https://example.com/PetStoreShopper?birds=available

API Gateway ruft die GET-Methode der /PetStoreShopper-Ressource mit dem Abfragezeichenfolgenparameter birds=available auf.

Einschränkungen

  • Die Ziel-API und der benutzerdefinierte Domainname müssen sich im selben AWS Konto befinden.

  • Jede Regel kann eine Ziel-API haben.

  • Sie können eine Routing-Regel nur für einen privaten benutzerdefinierten Domainnamen an eine private API und für einen öffentlichen benutzerdefinierten Domainnamen an eine öffentliche API erstellen. Sie können öffentliche und private Ressourcen nicht mischen.

  • Wenn Ihr benutzerdefinierter Domainname API-Zuordnungen sowohl zu REST als auch zu HTTP enthält APIs, werden Routing-Regeln nicht unterstützt.

  • Die maximal zulässige Priorität beträgt 1 000 000.

  • Header-Einschränkungen:

    • Jede anyOf Bedingung darf nur einen Header-Wert enthalten.

    • Die einzigen zulässigen Zeichen für Header-Namen und Header-Glob-Werte sind in RFC 7230 festgelegt. Dabei handelt es sich um a-z, A-Z, 0-9 und die folgenden Sonderzeichen: *?-!#$%&'.^_`|~.

    • Sie können einen Platzhalter im Header-Glob-Wert verwenden, jedoch muss der Platzhalter *prefix-match, suffix-match* oder *contains* sein. Sie können * nicht in der Mitte eines Header-Glob-Werts verwenden.

    • Platzhalter-Header-Namen werden nicht unterstützt.

    • Der Header-Name darf maximal 40 Zeichen lang sein.

    • Der Header-Glob-Wert darf maximal 128 Zeichen lang sein.

    • Der Header-Glob-Wert für eine Infix-Übereinstimmung darf maximal 40 Zeichen lang sein.

    • Die folgenden Header werden nicht als Bedingungen unterstützt:

      • access-control-*

      • apigw-*

      • Authorization

      • Connection

      • Content-Encoding

      • Content-Length

      • Content-Location

      • Forwarded

      • Keep-Alive

      • Origin

      • Proxy-Authenticate

      • Proxy-Authorization

      • TE

      • Trailers

      • Transfer-Encoding

      • Upgrade

      • x-amz-*

      • x-amzn-*

      • x-apigw-api-id

      • X-Forwarded-For

      • X-Forwarded-Host

      • X-Forwarded-Proto

      • x-restAPI

      • Via

  • Basispfadeinschränkungen:

    • Die Länge des Basispfads darf maximal 128 Zeichen betragen.

    • Der Basispfad darf nur Buchstaben, Zahlen und die folgenden Zeichen enthalten: $-_.+!*'()/.

      Diese Zeichen werden für reguläre Ausdrücke (Regex) nicht unterstützt.

    • Der Basispfad darf nicht mit einem umgekehrten Schrägstrich (\) beginnen oder enden.