Remarques importantes concernant Amazon API Gateway - APIPasserelle Amazon
Remarques importantes pour REST APIs HTTPAPIs, et WebSocket APIsRemarques importantes concernant Amazon API Gateway pour HTTP APIsRemarques importantes pour REST APIs et WebSocket APIsRemarques importantes pour WebSocket APIsRemarques importantes pour REST APIs

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Remarques importantes concernant Amazon API Gateway

La section suivante détaille les remarques susceptibles d'avoir un impact sur votre utilisation de API Gateway.

Remarques importantes concernant Amazon API Gateway pour REST APIs HTTPAPIs, et WebSocket APIs

  • Signature Version 4A n'est pas officiellement prise en charge par Amazon API Gateway.

Remarques importantes concernant Amazon API Gateway pour HTTP APIs

  • HTTPAPIstraduit les X-Forwarded-* en-têtes entrants en Forwarded en-tête standard et ajoutera l'IP de sortie, l'hôte et le protocole.

Remarques importantes concernant Amazon API Gateway pour REST et WebSocket APIs

  • APIGateway ne prend pas en charge le partage d'un nom de domaine personnalisé entre REST et WebSocket APIs.

  • Les noms d'étape peuvent contenir uniquement des caractères alphanumériques, des tirets et des traits de soulignement. La longueur maximale est de 128 caractères.

  • Les chemins d'accès /ping et /sping sont réservés à la vérification de l'état du service. Leur utilisation pour des ressources de API niveau racine avec des domaines personnalisés ne produira pas le résultat attendu.

  • APIGateway limite actuellement les événements de journal à 1 024 octets. Les événements de journal de plus de 1 024 octets, tels que les corps de demande et de réponse, seront tronqués par API Gateway avant d'être soumis à CloudWatch Logs.

  • CloudWatch Metrics limite actuellement les noms et les valeurs des dimensions à 255 XML caractères valides. (Pour plus d'informations, consultez le guide de CloudWatch l'utilisateur.) Les valeurs de dimension sont fonction des noms définis par l'utilisateur, notamment le API nom, le nom de l'étiquette (étape) et le nom de la ressource. Lorsque vous choisissez ces noms, veillez à ne pas dépasser CloudWatch les limites des métriques.

  • La taille maximale d'un modèle de mappage est de 300 Ko.

Remarques importantes API relatives à Amazon Gateway pour WebSocket APIs

  • APIGateway prend en charge des charges utiles de messages allant jusqu'à 128 Ko avec une taille de trame maximale de 32 Ko. Si un message dépasse 32 Ko, vous devez le diviser en plusieurs trames, chacune de 32 Ko ou moins. Si un message plus grand est reçu, la connexion se ferme avec le code 1009.

Remarques importantes concernant Amazon API Gateway pour REST APIs

  • Le caractère tube en texte brut (|) n'est pris en charge pour aucune chaîne de URL requête et doit être URL codé.

  • Le point-virgule (;) n'est pris en charge pour aucune chaîne de URL requête et entraîne le fractionnement des données.

  • RESTAPIsURLdécodez les paramètres de demande codés avant de les transmettre aux intégrations du backend. Pour les paramètres de requête UTF -8, REST APIs décodez-les puis transmettez-les en Unicode aux intégrations du backend.

  • Lorsque vous utilisez la console API Gateway pour tester unAPI, vous pouvez obtenir une réponse « erreurs de point de terminaison inconnues » si un certificat auto-signé est présenté au backend, si le certificat intermédiaire est absent de la chaîne de certificats ou si toute autre exception méconnaissable liée au certificat est émise par le backend.

  • Pour une Methodentité API Resourceou avec une intégration privée, vous devez la supprimer après avoir supprimé toute référence codée en dur à un VpcLink. Sinon, vous avez une intégration en suspens et vous recevez un message d'erreur indiquant que le VPC lien est toujours utilisé même lorsque l'Methodentité Resource ou est supprimée. Ce comportement ne s'applique pas lorsque l'intégration privée renvoie à VpcLink par le biais d'une variable d'étape.

  • Les backends suivants peuvent ne pas prendre en charge l'authentification du SSL client d'une manière compatible avec API Gateway :

  • APIGateway prend en charge la plupart des spécifications Open API 2.0 et Open API 3.0, avec les exceptions suivantes :

    • Les segments de chemin peuvent contenir uniquement des caractères alphanumériques, des tirets, des points, des virgules, des doubles points et des accolades. Les paramètres de chemin doivent être des segments de chemin distincts. Par exemple, « resource/{path_parameter_name} » est valide ; « resource{path_parameter_name} » ne l'est pas.

    • Les noms de modèle ne peuvent contenir que des caractères alphanumériques.

    • Pour les paramètres d'entrée, seuls les attributs suivants sont pris en charge: name, in, required, type, description. Les autres attributs sont ignorés.

    • S'il est utilisé, le type securitySchemes doit être apiKey. Cependant, les authentifications OAuth 2 et HTTP de base sont prises en charge via les autorisateurs Lambda ; la API configuration ouverte est réalisée via les extensions du fournisseur.

    • Le deprecated champ n'est pas pris en charge et est supprimé lors de l'exportationAPIs.

    • APILes modèles de passerelle sont définis à l'aide du brouillon de JSON schéma 4, au lieu du JSON schéma utilisé par OpenAPI.

    • Le paramètre discriminator n'est pris en charge dans aucun objet de schéma.

    • La balise example n'est pas prise en charge.

    • exclusiveMinimumn'est pas pris en charge par API Gateway.

    • Les balises maxItems et minItems ne sont pas incluses dans une validation de demande simple. Pour contourner ce problème, mettez à jour le modèle après l'importation avant d'effectuer la validation.

    • oneOfn'est pas pris en charge pour Open API 2.0 ou pour SDK la génération.

    • Le champ readOnly n'est pas pris en charge.

    • $ref ne peut pas être utilisé pour référencer d'autres fichiers.

    • Les définitions de réponse du "500": {"$ref": "#/responses/UnexpectedError"} formulaire ne sont pas prises en charge dans la racine du API document ouvert. Pour contourner ce problème, remplacez la référence par le schéma en ligne.

    • Les nombres de type Int32 ou Int64 ne sont pas pris en charge. Voici un exemple :

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

    • Le type de format décimal ("format": "decimal") n'est pas pris en charge dans une définition de schéma.

    • Dans les réponses de méthode, la définition de schéma doit être de type objet et ne peut pas avoir l'un des types primitifs. Par exemple, "schema": { "type": "string"} n'est pas pris en charge. Cependant, vous pouvez contourner ce problème à l'aide du type d'objet suivant :

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

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

    • APIGateway n'utilise pas la sécurité de niveau racine définie dans la API spécification Open. Par conséquent, la sécurité doit être définie au niveau de l'opération pour être appliquée correctement.

    • Le mot-clé default n'est pas pris en charge.

  • APIGateway applique les restrictions et limitations suivantes lors de la gestion des méthodes d'intégration Lambda ou d'intégrationHTTP.

    • Les noms d'en-tête et les paramètres de requête sont traités de manière sensible à la casse.

    • Le tableau suivant répertorie les en-têtes qui peuvent être abandonnés, remappés ou modifiés autrement lorsqu'ils sont envoyés au point de terminaison d'intégration ou renvoyés par le point de terminaison d'intégration. Dans ce tableau :

      • Remapped signifie que le nom d'en-tête <string> est remplacé par X-Amzn-Remapped-<string>.

        Remapped Overwritten signifie que le nom d'en-tête <string> est remplacé par X-Amzn-Remapped-<string> et que la valeur est écrasée.

      Nom de l'en-tête Requête (http/http_proxy/lambda) Réponse (http/http_proxy/lambda)
      Age Transmettre Transmettre
      Accept Transmettre Dropped/Passthrough/Passthrough
      Accept-Charset Transmettre Transmettre
      Accept-Encoding Transmettre Transmettre
      Authorization Transmettre * Remappé
      Connection Passthrough/Passthrough/Dropped Remappé
      Content-Encoding Passthrough/Dropped/Passthrough Transmettre
      Content-Length Transmette (généré sur la base du corps) Transmettre
      Content-MD5 A abandonné Remappé
      Content-Type Transmettre Transmettre
      Date Transmettre Remappé écrasé
      Expect A abandonné A abandonné
      Host Remplacé au point de terminaison d'intégration A abandonné
      Max-Forwards A abandonné Remappé
      Pragma Transmettre Transmettre
      Proxy-Authenticate A abandonné A abandonné
      Range Transmettre Transmettre
      Referer Transmettre Transmettre
      Server A abandonné Remappé écrasé
      TE A abandonné A abandonné
      Transfer-Encoding Dropped/Dropped/Exception A abandonné
      Trailer A abandonné A abandonné
      Upgrade A abandonné A abandonné
      User-Agent Transmettre Remappé
      Via Dropped/Dropped/Passthrough Passthrough/Dropped/Dropped
      Warn Transmettre Transmettre
      WWW-Authenticate A abandonné Remappé

      * L'en-tête Authorization est supprimé s'il contient une signature Signature Version 4 ou si une autorisation AWS_IAM est utilisée.

  • L'Android SDK d'un API généré par API Gateway utilise la java.net.HttpURLConnection classe. Cette classe lève une exception non prise en charge, sur les appareils Android 4.4 et version antérieures, dans le cas d'une réponse 401 résultant du remappage de l'en-tête WWW-Authenticate en X-Amzn-Remapped-WWW-Authenticate.

  • Contrairement à Java, Android et iOS API générés par Gateway, le SDKs JavaScript SDK de et API généré par API Gateway ne prend pas en charge les nouvelles tentatives pour les erreurs de niveau 500. API

  • Le test d'appel d'une méthode utilise le type de contenu application/json par défaut et ignore les spécifications de tous les autres types de contenu.

  • Lorsque vous envoyez des demandes à un API en transmettant l'X-HTTP-Method-Overrideen-tête, API Gateway remplace la méthode. Par conséquent, pour que l'en-tête soit transmise au backend, elle doit être ajoutée à la demande d'intégration.

  • Lorsqu'une demande contient plusieurs types de médias dans son Accept en-tête, API Gateway n'honore que le premier type de Accept média. Si vous ne pouvez pas contrôler l'ordre des types de Accept médias et que le type de support de votre contenu binaire n'est pas le premier de la liste, vous pouvez ajouter le premier type de Accept média dans la binaryMediaTypes liste de votre API contenu. API Gateway renverra votre contenu sous forme binaire. Par exemple, pour envoyer un JPEG fichier à l'aide d'un <img> élément d'un navigateur, celui-ci peut envoyer Accept:image/webp,image/*,*/*;q=0.8 une demande. En l'ajoutant image/webp à la binaryMediaTypes liste, le point de terminaison recevra le JPEG fichier sous forme binaire.

  • La personnalisation de la réponse de passerelle par défaut pour 413 REQUEST_TOO_LARGE n'est actuellement pas prise en charge.

  • APIGateway inclut un Content-Type en-tête pour toutes les réponses d'intégration. Par défaut, le type de contenu est application/json.