Comment gérer les intégrations proxy dans Amazon API Gateway avec AWS Serverless Application Model

Le Serverless Application Model (AWS SAM) est un outil puissant pour simplifier le processus de création d’une API Gateway pour vos applications serverless sur AWS comparé à la déclaration des ressources CloudFormation natives. Cependant, une question se pose : que faire lorsque vous avez besoin d’ajouter des intégrations autres que des fonctions Lambda, telles que l’intégration HTTP_PROXY ?

Dans cet article, nous allons explorer comment utiliser AWS SAM pour gérer divers types d’intégrations, tout en évitant les écueils potentiels.

Les limitations d’AWS SAM

Avant d’entrer dans les détails de la solution, il est essentiel de comprendre les limitations d’AWS SAM. Il est excellent pour la création d’API Gateway avec des fonctions Lambda, mais il ne propose pas nativement de ressource pour définir des intégrations HTTP_PROXY. De plus, il est fortement déconseillé d’utiliser la ressource AWS::Serverless::Api avec les ressources AWS::ApiGateway::Method ou AWS::ApiGateway::Resource, car cela peut entraîner des comportements imprévisibles tel que l’écrasement des ressources défini via CloudFormation par AWS SAM et donc des endpoints risquent d’être manquants.

Utilisation de Spécifications OpenAPI

La solution pour ajouter des intégrations HTTP_PROXY tout en continuant à utiliser AWS SAM consiste à créer une spécification OpenAPI (anciennement Swagger).

Pour définir vos intégrations voici comment procéder :

Créez votre spécification OpenAPI : Rédigez la spécification OpenAPI qui décrit les intégrations que vous souhaitez ajouter à votre API Gateway. Vous pouvez utiliser des outils tels que Swagger Editor ou écrire la spécification manuellement.
Intégrez la spécification dans AWS::Serverless::Api : Ajoutez la spécification OpenAPI dans la définition de votre API en utilisant la clé DefinitionBody. Cela permettra à AWS SAM de prendre en compte les intégrations HTTP_PROXY lors du déploiement.
Activez la Fusion des Définitions : Assurez-vous d’ajouter la clé MergeDefinitions: true dans votre définition pour que les spécifications OpenAPI que vous avez fournies soient fusionnées avec celles générées par AWS SAM.

Exemple Pratique

Pour mieux comprendre cette approche, considérons un exemple concret. Supposons que vous ayez une API serverless qui doit interagir avec un service tiers via une intégration HTTP_PROXY. Voici comment vous pourriez le faire :

  MyApi:
    Type: AWS::Serverless::Api
    Properties:
      Name: MyAPI
      StageName: example
      DefinitionBody:
        openapi: "3.0.3"
        info:
          version: 1.0.0
          title: My title
        paths:
          /example:
            post:
              responses: { }
              x-amazon-apigateway-integration:
                type: "http_proxy"
                httpMethod: "POST"
                uri: "https://httpbin.org/anything/example"
                passthroughBehavior: "when_no_match"
      MergeDefinitions: true

Dans cet exemple, la specification OpenApi permet au service Amazon Api Gateway de transférer la requête POST /example directement vers un serveur web tier sans exposer l’url au client.

Conclusion

Utiliser AWS SAM pour gérer votre API Gateway est une excellente idée, quel que soit le type d’intégration que vous devez gérer. En utilisant des spécifications OpenAPI et en activant la fusion des définitions, vous pouvez ajouter des intégrations de manière simple et efficace. Cela vous permet de profiter de la simplicité d’AWS SAM tout en ayant la flexibilité nécessaire pour gérer des scénarios plus complexes.

Comment gérer les intégrations proxy dans Amazon API Gateway avec AWS Serverless Application ModelBlog