Wichtige Hinweise zu Amazon API Gateway - Amazon API Gateway
Wichtige Hinweise für REST- und WebSocket-APIsWichtige Hinweise für WebSocket-APIsWichtige Hinweise für REST-APIs

Wichtige Hinweise zu Amazon API Gateway

Amazon API Gateway – Wichtige Hinweise für REST- und WebSocket-APIs

  • API Gateway unterstützt nicht die gemeinsame Nutzung eines benutzerdefinierten Domänennamens durch REST-APIs und WebSocket-APIs.

  • Phasennamen dürfen nur alphanumerische Zeichen sowie Binde- und Unterstriche enthalten. Die maximale Länge beträgt 128 Zeichen.

  • Die Pfade /ping und /sping sind für die Servicezustandsprüfung reserviert. Wenn diese für API-Ressourcen auf Stammebene mit benutzerdefinierten Domains verwendet werden, liefern sie nicht das erwartete Ergebnis.

  • API Gateway begrenzt Protokollereignisse derzeit auf 1024 Bytes. Protokollereignisse, die größer als 1024 Bytes sind, z. B. Anforderungs- und Antworttextkörper, werden vom API Gateway gekürzt, bevor sie an CloudWatch Logs gesendet werden.

  • CloudWatch Metrics begrenzt Dimensionsnamen und -werte derzeit auf 255 gültige XML-Zeichen. (Weitere Informationen finden Sie im CloudWatch-Benutzerhandbuch.) Dimensionenwerte sind eine Funktion benutzerdefinierter Namen, einschließlich API-Name, Bezeichnung (Stufenname) und Ressourcenname. Achten Sie bei der Auswahl dieser Namen darauf, die Grenzen der CloudWatch-Metrik nicht zu überschreiten.

  • Die maximale Größe einer Zuordnungsvorlage beträgt 300 KB.

Amazon API Gateway – Wichtige Hinweise für WebSocket-APIs

  • API Gateway unterstützt Nachrichten-Payloads bis zu 128 KB mit einer maximalen Frame-Größe von 32 KB. Sie müssen Nachrichten, die 32 KB überschreiten, in mehrere Frames aufteilen, die jeweils 32 KB oder kleiner sind. Wenn eine größere Nachricht empfangen wird, wird die Verbindung mit Code 1009 geschlossen.

Amazon API Gateway – Wichtige Hinweise für REST-APIs

  • Das Pipe-Klartextzeichen (|) wird in Abfragezeichenfolgen zur Anforderung einer URL nicht unterstützt und muss URL-kodiert werden.

  • Das Semikolon (;) wird in Abfragezeichenfolgen zur Anforderung einer URL nicht unterstützt und führt dazu, dass die Daten aufgeteilt werden. Im Allgemeinen dekodieren REST-APIs URL-kodierte Anforderungsparameter vor deren Übergabe an Backend-Integrationen.

  • Beim Verwenden der Amazon API Gateway-Konsole zum Testen einer API können Sie die Antwort "unknown endpoint errors" erhalten, wenn auf dem Backend ein selbstsigniertes Zertifikat präsentiert wird, in der Zertifikatkette ein Zwischenzertifikat fehlt oder das Backend eine andere, nicht erkennbare zertifikatbezogenen Ausnahme auslöst.

  • Sie sollten eine API-Resource oder Method-Entität mit einer privaten Integration löschen, nachdem Sie hartcodierte Referenzen eines VpcLink entfernt haben. Andernfalls ist die Integration nicht abgeschlossen und Sie erhalten eine Fehlermeldung mit dem Hinweis, dass der VPC-Link noch verwendet wird, obwohl die Entität Resource oder Method gelöscht wurde. Dieses Verhalten liegt nicht vor, wenn die private Integration über eine Stufenvariable auf VpcLink verweist.

  • Die folgenden Backends unterstützen die SSL-Clientauthentifizierung möglicherweise nicht auf eine mit API Gateway kompatible Weise:

  • API Gateway unterstützt die meisten der OpenAPI-2.0-Spezifikation und der OpenAPI-3.0-Spezifikation mit den folgenden Ausnahmen:

    • Pfadsegmente dürfen nur alphanumerische Zeichen, Unterstriche, Bindestriche, Punkte, Kommas, Doppelpunkte und geschweifte Klammern enthalten. Pfadparameter müssen als separate Pfadsegmente vorliegen. Beispiel: "resource/{path_parameter_name}" ist gültig, "resource{path_parameter_name}" nicht.

    • Modellnamen dürfen nur alphanumerische Zeichen enthalten.

    • Als Eingabeparameter werden nur die folgenden Attribute unterstützt: name, in, required, type, description. Andere Attribute werden ignoriert.

    • Der securitySchemes-Typ muss bei Verwendung apiKey lauten. Die OAuth 2- und HTTP-Standardauthentifizierung wird jedoch über Lambda-Genehmiger unterstützt die OpenAPI-Konfiguration wird über Anbietererweiterungen ermöglicht.

    • Das Feld deprecated wird nicht unterstützt und aus exportierten APIs entfernt.

    • API Gateway-Modelle werden unter Verwendung von JSON-Schemaentwurf 4 anstelle des von OpenAPI verwendeten JSON-Schemas definiert.

    • Der Parameter discriminator wird in Schemaobjekten nicht unterstützt.

    • Das Tag example wird nicht unterstützt.

    • exclusiveMinimum wird von API Gateway nicht unterstützt.

    • Die Tags maxItems und minItems werden bei der einfachen Anforderungsvalidierung nicht berücksichtigt. Um dieses Problem zu umgehen, aktualisieren Sie das Modell nach dem Import, bevor Sie die Validierung vornehmen.

    • oneOf wird für OpenAPI 2.0 oder die SDK-Generierung nicht unterstützt.

    • Das Feld readOnly wird nicht unterstützt.

    • Antwortdefinitionen des Formulars "500": {"$ref": "#/responses/UnexpectedError"} werden im OpenAPI-Basisverzeichnis nicht unterstützt. Ersetzen Sie die Referenz durch das Inline-Schema, um dieses Problem zu umgehen.

    • Zahlen vom Typ Int32 oder Int64 werden nicht unterstützt. Ein Beispiel sehen Sie unten:

      "elementId": {
    "description": "Working Element Id",
    "format": "int32",
    "type": "number"
}

    • Der Formattyp Dezimalzahl ("format": "decimal") wird in Schemadefinitionen nicht unterstützt.

    • In Methodenantworten muss die Schemadefinition ein Objekttyp sein und darf keine primitiven Datentypen umfassen. Beispielsweise wird "schema": { "type": "string"} nicht unterstützt. Sie können dies jedoch umgehen, indem Sie den folgenden Objekttyp verwenden:

      "schema": {
     "$ref": "#/definitions/StringResponse"
            }

 "definitions": {
    "StringResponse": {
      "type": "string"
    }
  }

    • API Gateway verwendet keine in der OpenAPI-Spezifikation definierte Sicherheit auf Stammebene. Daher muss die Sicherheit auf Vorgangsebene definiert werdne, um korrekt angewendet werden zu können.

    • Das default-Schlüsselwort wird nicht unterstützt.

  • API Gateway führt die folgenden Beschränkungen und Limitierungen bei der Handhabung von Methoden mit Lambda- oder HTTP-Integration durch.

    • Bei der Verarbeitung von Header-Namen und Abfrageparametern wird die Groß- und Kleinschreibung beachtet.

    • Die folgende Tabelle listet die Header auf, die gelöscht, erneut zugewiesen oder anderweitig modifiziert werden können, wenn sie an den Integrationsendpunkt oder von diesem zurückgesendet werden. In dieser Tabelle:

      • Remapped bedeutet, dass der Header-Name von <string> in X-Amzn-Remapped-<string> geändert wird.

        Remapped Overwritten bedeutet, dass der Header-Name von <string> in X-Amzn-Remapped-<string> geändert und der Wert überschrieben wird.

      Header-Name Anfrage (http/http_proxy/lambda) Antwort (http/http_proxy/lambda)
      Age Pass-Through Pass-Through
      Accept Pass-Through Gelöscht/Pass-Through/Pass-Through
      Accept-Charset Pass-Through Pass-Through
      Accept-Encoding Pass-Through Pass-Through
      Authorization Pass-Through* Remapped
      Connection Pass-Through/Pass-Through/Gelöscht Remapped
      Content-Encoding Pass-Through/Gelöscht/Pass-Through Pass-Through
      Content-Length Pass-Through (generiert auf der Grundlage des Inhalts) Pass-Through
      Content-MD5 Gelöscht Remapped
      Content-Type Pass-Through Pass-Through
      Date Pass-Through Neu zugeordnet überschrieben
      Expect Gelöscht Gelöscht
      Host Auf den Integrationsendpunkt überschrieben Gelöscht
      Max-Forwards Gelöscht Remapped
      Pragma Pass-Through Pass-Through
      Proxy-Authenticate Gelöscht Gelöscht
      Range Pass-Through Pass-Through
      Referer Pass-Through Pass-Through
      Server Gelöscht Neu zugeordnet überschrieben
      TE Gelöscht Gelöscht
      Transfer-Encoding Gelöscht/Gelöscht/Ausnahme Gelöscht
      Trailer Gelöscht Gelöscht
      Upgrade Gelöscht Gelöscht
      User-Agent Pass-Through Remapped
      Via Gelöscht/Gelöscht/Pass-Through Pass-Through/Gelöscht/Gelöscht
      Warn Pass-Through Pass-Through
      WWW-Authenticate Gelöscht Remapped

      * Der Authorization-Header wird gelöscht, wenn er eine Signaturversion 4-Signatur enthält.

  • Das Android-SDK einer von API Gateway generierten API verwendet die Klasse java.net.HttpURLConnection. Diese Klasse löst auf Geräten, auf denen Android 4.4 und früher ausgeführt wird, eine unbehandelte Ausnahme für eine 401-Antwort aus, die aus der Neuzuordnung des Headers WWW-Authenticate zu X-Amzn-Remapped-WWW-Authenticate resultiert.

  • Im Gegensatz zu den von API Gateway generierten Java-, Android- und iOS-SDKs einer API unterstützt das JavaScript-SDK einer von API Gateway generierten API keine Wiederholungsversuche für Level-500-Fehler.

  • Der Test-Aufruf einer Methode verwendet den Standard-Inhaltstyp application/json und ignoriert Spezifikationen anderer Inhaltstypen.

  • Beim Senden von Anfragen an eine API durch Übergabe des X-HTTP-Method-Override-Headers überschreibt API Gateway die Methode. Um den Header an das Backend zu übergeben, muss der Header der Integrationsanforderung hinzugefügt werden.

  • Wenn eine Anfrage mehrere Medientypen in ihrem Accept-Header enthält, berücksichtigt API Gateway nur den ersten Accept-Medientyp. Wenn Sie die Reihenfolge der Accept-Medientypen nicht steuern können und der Medientyp Ihres binären Inhalts nicht der erste in der Liste ist, können Sie den ersten Accept-Medientyp in der Liste binaryMediaTypes Ihrer API hinzufügen. Amazon API Gateway gibt Ihren Inhalt dann im Binärformat zurück. Um z. B. eine JPEG-Datei mit einem <img>-Element in einem Browser zu übermitteln, sendet der Browser möglicherweise Accept:image/webp,image/*,*/*;q=0.8 in einer Anforderung. Bei Hinzufügen von image/webp zur Liste binaryMediaTypes erhält der Endpunkt die JPEG-Datei als Binärdatei.

  • Das Anpassen der Standard-Gateway-Antwort für 413 REQUEST_TOO_LARGE wird derzeit nicht unterstützt.

  • API Gateway enthält einen Content-Type-Header für alle Integrationsantworten. Der Inhaltstyp ist standardmäßig „application/json“.