Configuration d'intégrations de proxy Lambda dans API Gateway

Présentation de l'intégration de proxy Lambda API Gateway

L'intégration de proxy Lambda Amazon API Gateway est un mécanisme simple, puissant et agile pour créer une API avec la configuration d'une seule méthode d'API. L'intégration de proxy Lambda permet au client d'appeler une seule fonction Lambda du backend. La fonction accède à de nombreuses ressources ou fonctionnalités d'autres AWS services, notamment en appelant d'autres fonctions Lambda.

Dans l'intégration de proxy Lambda, quand un client envoie une demande d'API, API Gateway transmet à la fonction Lambda intégrée un objet d'événement, si ce n'est que l'ordre des paramètres de la demande n'est pas préservé. Les données de la demande incluent les en-têtes de demande, les paramètres de chaîne de requête, les variables du chemin de l'URL, la charge utile et les données de configuration de l'API. Les données de configuration peuvent inclure le nom de la phase de déploiement en cours, les variables de la phase, l'identité de l'utilisateur ou le contexte d'autorisation (le cas échéant). La fonction Lambda du backend analyse les données de la demande entrante pour déterminer la réponse qu'elle renvoie. Pour qu'API Gateway transmette la sortie Lambda comme réponse de l'API au client, la fonction Lambda doit renvoyer le résultat dans ce format.

Dans la mesure où API Gateway n'intervient pas beaucoup entre le client et la fonction Lambda du backend pour l'intégration de proxy Lambda, le client et la fonction Lambda intégrée peuvent s'adapter aux modifications de l'autre sans interrompre la configuration de l'intégration existante de l'API. Pour ce faire, le client doit suivre les protocoles d'application édictés par la fonction Lambda du backend.

Vous pouvez configurer une intégration de proxy Lambda pour n'importe quelle méthode d'API. Mais une intégration de proxy Lambda est plus puissante quand elle est configurée pour une méthode d'API impliquant une ressource de proxy générique. La ressource de proxy générique peut être symbolisée par la variable spéciale de chemin modélisé {proxy+}, l'espace réservé de la méthode fourre-tout ANY, ou les deux. Le client peut transmettre les entrées de la fonction Lambda du backend dans la demande entrante comme paramètres de la demande ou comme charge utile applicable. Les paramètres de la demande comprennent les en-têtes, les variables du chemin de l'URL, les paramètres de la chaîne de requête et la charge utile applicable. La fonction Lambda intégrée vérifie l'ensemble des sources d'entrée avant de traiter la demande et de répondre au client avec des messages d'erreur significatifs si l'une des entrées requises est manquante.

Lors de l'appel d'une méthode d'API intégrée avec la méthode HTTP générique ANY et la ressource générique {proxy+}, le client soumet une demande avec une méthode HTTP particulière à la place de ANY. Le client spécifie également un chemin d'URL particulier au lieu de {proxy+} et inclut tous les en-têtes requis, les paramètres de chaîne de requête ou une charge utile applicable.

La liste suivante résume les comportements d'exécution de différentes méthodes d'API avec l'intégration de proxy Lambda :

• ANY /{proxy+} : le client doit choisir une méthode HTTP particulière, doit définir une hiérarchie de chemins de ressources spécifiques et peut définir des en-têtes, des paramètres de chaîne de requête et une charge utile applicable pour transmettre les données en tant qu'entrées de la fonction Lambda intégrée.

• ANY /res : le client doit choisir une méthode HTTP particulière et peut définir des en-têtes, des paramètres de chaîne de requête et une charge utile applicable pour transmettre les données en tant qu'entrées de la fonction Lambda intégrée.

• GET|POST|PUT|... /{proxy+} : le client peut définir une hiérarchie de chemins de ressources spécifiques, des en-têtes, des paramètres de chaîne de requête et une charge utile applicable pour transmettre les données en tant qu'entrées de la fonction Lambda intégrée.

• GET|POST|PUT|... /res/{path}/... : le client doit choisir un segment de chemin particulier (pour la variable {path}) et peut définir des en-têtes de demande, des paramètres de chaîne de requête et une charge utile applicable pour transmettre les données en entrée à la fonction Lambda intégrée.

• GET|POST|PUT|... /res : le client peut choisir des en-têtes de demande, des paramètres de chaîne de requête et une charge utile applicable pour transmettre les données en entrée à la fonction Lambda intégrée.

Dans les deux cas, la ressource de proxy {proxy+} et la ressource personnalisée {custom} sont exprimées comme des variables de chemin modélisé. Cependant, {proxy+} peut faire référence à n'importe quelle ressource de la hiérarchie des chemins, tandis que {custom} ne fait référence qu'à un segment de chemin particulier. Par exemple, une épicerie peut organiser son stock de produits en ligne par noms de département, catégories de produit et types de produits. Le site web de l'épicerie peut alors représenter les produits disponibles par les variables de chemin modélisé suivantes des ressources personnalisée: /{department}/{produce-category}/{product-type}. Par exemple, les pommes sont représentées par /produce/fruit/apple et les carottes par /produce/vegetables/carrot. Le site peut également utiliser /{proxy+} pour représenter n'importe quel département, catégorie de produit ou type de produit qu'un client peut rechercher lors de ses achats dans la boutique en ligne. Par exemple, /{proxy+} peut faire référence à l'un des articles suivants :

• /produce

• /produce/fruit

• /produce/vegetables/carrot

Pour permettre aux clients de rechercher n'importe quel produit disponible, sa catégorie et le département du magasin associé, vous pouvez exposer une seule méthode GET /{proxy+} avec les autorisations en lecture seule. De même, pour autoriser un superviseur à mettre à jour le stock du département produce, vous pouvez configurer une autre méthode unique PUT /produce/{proxy+} avec les autorisations en lecture/écriture. Pour autoriser une caissière pour mettre à jour le total cumulé d'un légume, vous pouvez configurer une méthode POST /produce/vegetables/{proxy+} avec les autorisations en lecture/écriture. Pour permettre à un gestionnaire de stockage d'effectuer n'importe quelle action possible sur n'importe quel produit disponible, le développeur de la boutique en ligne peut exposer la méthode ANY /{proxy+} avec les autorisations en lecture/écriture. Dans tous les cas, au moment de l'exécution, le client ou l'employé doit sélectionner un produit spécifique d'un type donné dans un département choisi, une catégorie de produits spécifique d'un département donné ou un département spécifique.

Pour de plus amples informations sur la configuration des intégrations de proxy API Gateway, veuillez consulter Configuration de l'intégration de proxy avec une ressource de proxy.

L'intégration de proxy nécessite que le client ait une connaissance plus approfondie des exigences du backend. Par conséquent, pour garantir des performances d'application et une expérience de l'utilisateur optimales, le développeur du backend doit communiquer clairement au développeur du client les exigences du backend et fournir un mécanisme de retour d'erreur robuste lorsque les exigences ne sont pas satisfaites.

Prise en charge des en-têtes à valeurs multiples et des paramètres de chaîne de requête

API Gateway prend désormais en charge les en-têtes multiples et les paramètres de chaîne de requête portant le même nom. Les en-têtes à valeurs multiples et les en-têtes et paramètres à valeur unique peuvent être combinés dans les mêmes demandes et réponses. Pour plus d’informations, consultez Format d'entrée d'une fonction Lambda pour l'intégration proxy et Format de sortie d'une fonction Lambda pour l'intégration proxy.

Configuration d'une ressource de proxy avec l'intégration de proxy Lambda

Pour configurer une ressource de proxy avec le type d'intégration de proxy Lambda, créez une ressource d'API avec un paramètre de chemin gourmand (par exemple, /parent/{proxy+}) et intégrez cette ressource à un backend de fonction Lambda (par exemple, arn:aws:lambda:us-west-2:123456789012:function:SimpleLambda4ProxyResource) sur la méthode ANY. Le paramètre de chemin gourmand doit se trouver à la fin du chemin de ressource d'API. Comme avec une ressource autre que de proxy, vous pouvez configurer la ressource de proxy à l'aide de la console API Gateway, en important un fichier de définitions OpenAPI ou en appelant l'API REST API Gateway directement.

Le fichier de définitions d'API OpenAPI suivant présente un exemple d'API avec une ressource de proxy intégrée à une fonction Lambda nommée SimpleLambda4ProxyResource.

OpenAPI 3.0

{
   "openapi": "3.0.0",
   "info": {
      "version": "2016-09-12T17:50:37Z",
      "title": "ProxyIntegrationWithLambda"
   },
   "paths": {
      "/{proxy+}": {
         "x-amazon-apigateway-any-method": {
            "parameters": [
               {
                  "name": "proxy",
                  "in": "path",
                  "required": true,
                  "schema": {
                     "type": "string"
                  }
               }
            ],
            "responses": {},
            "x-amazon-apigateway-integration": {
               "responses": {
                  "default": {
                     "statusCode": "200"
                  }
               },
               "uri": "arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:123456789012:function:SimpleLambda4ProxyResource/invocations",
               "passthroughBehavior": "when_no_match",
               "httpMethod": "POST",
               "cacheNamespace": "roq9wj",
               "cacheKeyParameters": [
                  "method.request.path.proxy"
               ],
               "type": "aws_proxy"
            }
         }
      }
   },
   "servers": [
      {
         "url": "https://gy415nuibc.execute-api.us-east-1.amazonaws.com/{basePath}",
         "variables": {
            "basePath": {
              "default": "/testStage"
            }
         }
      }
   ]
}

OpenAPI 2.0

{
  "swagger": "2.0",
  "info": {
    "version": "2016-09-12T17:50:37Z",
    "title": "ProxyIntegrationWithLambda"
  },
  "host": "gy415nuibc.execute-api.us-east-1.amazonaws.com",
  "basePath": "/testStage",
  "schemes": [
    "https"
  ],
  "paths": {
    "/{proxy+}": {
      "x-amazon-apigateway-any-method": {
        "produces": [
          "application/json"
        ],
        "parameters": [
          {
            "name": "proxy",
            "in": "path",
            "required": true,
            "type": "string"
          }
        ],
        "responses": {},
        "x-amazon-apigateway-integration": {
          "responses": {
            "default": {
              "statusCode": "200"
            }
          },
          "uri": "arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:123456789012:function:SimpleLambda4ProxyResource/invocations",
          "passthroughBehavior": "when_no_match",
          "httpMethod": "POST",
          "cacheNamespace": "roq9wj",
          "cacheKeyParameters": [
            "method.request.path.proxy"
          ],
          "type": "aws_proxy"
        }
      }
    }
  }
}

Avec l'intégration de proxy Lambda, au moment de l'exécution, API Gateway mappe une demande entrante dans le paramètre d'entrée event de la fonction Lambda. L'entrée inclut la méthode de demande, le chemin, les en-têtes, les paramètres de chaîne de demande, la charge utile, le contexte associé et les variables d'étape définies. Le format d'entrée est expliqué dans Format d'entrée d'une fonction Lambda pour l'intégration proxy. Pour qu'API Gateway mappe correctement la sortie Lambda aux réponses HTTP, la fonction Lambda doit sortir le résultat au format décrit dans Format de sortie d'une fonction Lambda pour l'intégration proxy.

Avec l'intégration de proxy Lambda d'une ressource de proxy via la méthode ANY, la fonction Lambda du backend unique sert de gestionnaire d'événements pour toutes les demandes via la ressource de proxy. Par exemple, pour consigner les modèles de trafic, vous pouvez demander à un appareil mobile d'envoyer ses informations de localisation, notamment l'état, la ville, la rue et le bâtiment en soumettant une demande avec /state/city/street/house dans le chemin d'URL de la ressource de proxy. La fonction Lambda du backend peut ensuite analyser le chemin d'URL et insérer les tuples d'emplacement dans une table DynamoDB.

Configurez l'intégration du proxy Lambda à l'aide du AWS CLI

Dans cette section, nous montrons comment AWS CLI configurer une API avec l'intégration du proxy Lambda.

Note

Pour obtenir des instructions détaillées sur l'utilisation de la console API Gateway afin de configurer une ressource de proxy avec l'intégration de proxy Lambda, veuillez consulter Tutoriel : Création d'une API REST Hello World avec l'intégration de proxy Lambda.

À titre d'exemple, nous utilisons l'exemple suivant de fonction Lambda comme backend de l'API :

export const handler = function(event, context, callback) {
    console.log('Received event:', JSON.stringify(event, null, 2));
    var res ={
        "statusCode": 200,
        "headers": {
            "Content-Type": "*/*"
        }
    };
    var greeter = 'World';
    if (event.greeter && event.greeter!=="") {
        greeter =  event.greeter;
    } else if (event.body && event.body !== "") {
        var body = JSON.parse(event.body);
        if (body.greeter && body.greeter !== "") {
            greeter = body.greeter;
        }
    } else if (event.queryStringParameters && event.queryStringParameters.greeter && event.queryStringParameters.greeter !== "") {
        greeter = event.queryStringParameters.greeter;
    } else if (event.multiValueHeaders && event.multiValueHeaders.greeter && event.multiValueHeaders.greeter != "") {
        greeter = event.multiValueHeaders.greeter.join(" and ");
    } else if (event.headers && event.headers.greeter && event.headers.greeter != "") {
        greeter = event.headers.greeter;
    } 
    
    res.body = "Hello, " + greeter + "!";
    callback(null, res);
};

Si l'on compare ce code à la configuration de l'intégration personnalisée Lambda, l'entrée pour cette fonction Lambda peut être exprimée dans les paramètres et le corps de la demande. Vous avez plus de latitude pour permettre au client de transmettre les mêmes données d'entrée. Ici, le client peut transmettre le nom de l'hôte sous la forme d'une propriété de paramètre de chaîne de demande, d'en-tête ou de corps. La fonction peut également prendre en charge l'intégration personnalisée Lambda. La configuration de l'API est plus simple. Vous ne configurez pas du tout la réponse de la méthode ou la réponse de l'intégration.

Pour configurer une intégration de proxy Lambda à l'aide du AWS CLI

1. Appelez la commande create-rest-api pour créer une API :

   aws apigateway create-rest-api --name 'HelloWorld (AWS CLI)' --region us-west-2

   Notez la valeur d'id (te6si5ach7) de l'API résultante dans la réponse :

   {
       "name": "HelloWorldProxy (AWS CLI)", 
       "id": "te6si5ach7", 
       "createdDate": 1508461860
   }

   Vous avez besoin de l'id d'API tout au long de cette section.

2. Appelez la commande get-resources pour obtenir l'id de la ressource racine :

   aws apigateway get-resources --rest-api-id te6si5ach7 --region us-west-2

   La réponse positive est affichée comme suit :

   {
       "items": [
           {
               "path": "/", 
               "id": "krznpq9xpg"
           }
       ]
   }

   Notez la valeur d'id de la ressource racine (krznpq9xpg). Vous en aurez besoin à l'étape suivante et ultérieurement.

3. Appelez create-resource pour créer une ressource API Gateway /greeting :

   aws apigateway create-resource --rest-api-id te6si5ach7 \
         --region us-west-2 \
         --parent-id krznpq9xpg \
         --path-part {proxy+}

   La réponse positive est semblable à ce qui suit :

   {
       "path": "/{proxy+}", 
       "pathPart": "{proxy+}", 
       "id": "2jf6xt", 
       "parentId": "krznpq9xpg"
   }

   Notez la valeur d'id (2jf6xt) de la ressource {proxy+} résultante. Vous en avez besoin pour créer une méthode dans la ressource /{proxy+} à l'étape suivante.

4. Appelez put-method pour créer une demande de méthode ANY de ANY /{proxy+} :

   aws apigateway put-method --rest-api-id te6si5ach7 \
          --region us-west-2 \
          --resource-id 2jf6xt \
          --http-method ANY \
          --authorization-type "NONE" 

   La réponse positive est semblable à ce qui suit :

   {
       "apiKeyRequired": false, 
       "httpMethod": "ANY", 
       "authorizationType": "NONE"
   }

   Cette méthode d'API permet au client de recevoir ou d'envoyer des salutations de la fonction Lambda au backend.

5. Appelez put-integration pour configurer l'intégration de la méthode ANY /{proxy+} avec une fonction Lambda nommée HelloWorld. Cette fonction répond à la demande par un message "Hello, {name}!" si le paramètre greeter est précisé, ou "Hello, World!" si le paramètre de chaîne de demande n'est pas défini.

   aws apigateway put-integration \
           --region us-west-2 \
           --rest-api-id te6si5ach7 \
           --resource-id 2jf6xt \
           --http-method ANY \
           --type AWS_PROXY \
           --integration-http-method POST \
           --uri arn:aws:apigateway:us-west-2:lambda:path/2015-03-31/functions/arn:aws:lambda:us-west-2:123456789012:function:HelloWorld/invocations \
           --credentials arn:aws:iam::123456789012:role/apigAwsProxyRole

   Important

   Pour les intégrations Lambda, vous devez utiliser la méthode HTTP POST pour la demande d'intégration, conformément à la spécification de l'action de service Lambda pour les appels de fonction. Le rôle IAM apigAwsProxyRole doit avoir des stratégies permettant au service apigateway d'appeler des fonctions Lambda. Pour plus d'informations sur les autorisations IAM, consultez Modèle d'autorisation API Gateway pour l'appel d'une API.

   La sortie positive est semblable à ce qui suit :

   {
       "passthroughBehavior": "WHEN_NO_MATCH", 
       "cacheKeyParameters": [], 
       "uri": "arn:aws:apigateway:us-west-2:lambda:path/2015-03-31/functions/arn:aws:lambda:us-west-2:1234567890:function:HelloWorld/invocations", 
       "httpMethod": "POST", 
       "cacheNamespace": "vvom7n", 
       "credentials": "arn:aws:iam::1234567890:role/apigAwsProxyRole", 
       "type": "AWS_PROXY"
   }

   Plutôt que de préciser un rôle IAM pour credentials, vous pouvez appeler la commande add-permission pour ajouter des autorisations basées sur les ressources. C'est ce que fait la console API Gateway.

6. Appelez create-deployment pour déployer l'API dans une étape de test :

   aws apigateway create-deployment --rest-api-id te6si5ach7 --stage-name test --region us-west-2

7. Testez l'API à l'aide des commandes cURL suivantes dans un terminal.

   Appel de l'API avec le paramètre de chaîne de demande ?greeter=jane :

   curl -X GET 'https://te6si5ach7.execute-api.us-west-2.amazonaws.com/test/greeting?greeter=jane'

   Appel de l'API avec un paramètre d'en-tête greeter:jane :

   curl -X GET https://te6si5ach7.execute-api.us-west-2.amazonaws.com/test/hi \
     -H 'content-type: application/json' \
     -H 'greeter: jane'

   Appel de l'API avec un corps {"greeter":"jane"} :

   curl -X POST https://te6si5ach7.execute-api.us-west-2.amazonaws.com/test/hi \
     -H 'content-type: application/json' \
     -d '{ "greeter": "jane" }'

   Dans tous les cas, la sortie est une réponse 200 avec le corps de réponse suivant :

   Hello, jane!

Format d'entrée d'une fonction Lambda pour l'intégration proxy

Avec l'intégration de proxy Lambda, API Gateway mappe l'intégralité de la demande du client avec le paramètre event en entrée de la fonction Lambda du backend. L'exemple suivant montre la structure d'un événement qu’API Gateway envoie à une intégration de proxy Lambda.

{
  "resource": "/my/path",
  "path": "/my/path",
  "httpMethod": "GET",
  "headers": {
    "header1": "value1",
    "header2": "value1,value2"
  },
  "multiValueHeaders": {
    "header1": [
      "value1"
    ],
    "header2": [
      "value1",
      "value2"
    ]
  },
  "queryStringParameters": {
    "parameter1": "value1,value2",
    "parameter2": "value"
  },
  "multiValueQueryStringParameters": {
    "parameter1": [
      "value1",
      "value2"
    ],
    "parameter2": [
      "value"
    ]
  },
  "requestContext": {
    "accountId": "123456789012",
    "apiId": "id",
    "authorizer": {
      "claims": null,
      "scopes": null
    },
    "domainName": "id.execute-api.us-east-1.amazonaws.com",
    "domainPrefix": "id",
    "extendedRequestId": "request-id",
    "httpMethod": "GET",
    "identity": {
      "accessKey": null,
      "accountId": null,
      "caller": null,
      "cognitoAuthenticationProvider": null,
      "cognitoAuthenticationType": null,
      "cognitoIdentityId": null,
      "cognitoIdentityPoolId": null,
      "principalOrgId": null,
      "sourceIp": "IP",
      "user": null,
      "userAgent": "user-agent",
      "userArn": null,
      "clientCert": {
        "clientCertPem": "CERT_CONTENT",
        "subjectDN": "www.example.com",
        "issuerDN": "Example issuer",
        "serialNumber": "a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1",
        "validity": {
          "notBefore": "May 28 12:30:02 2019 GMT",
          "notAfter": "Aug  5 09:36:04 2021 GMT"
        }
      }
    },
    "path": "/my/path",
    "protocol": "HTTP/1.1",
    "requestId": "id=",
    "requestTime": "04/Mar/2020:19:15:17 +0000",
    "requestTimeEpoch": 1583349317135,
    "resourceId": null,
    "resourcePath": "/my/path",
    "stage": "$default"
  },
  "pathParameters": null,
  "stageVariables": null,
  "body": "Hello from Lambda!",
  "isBase64Encoded": false
}

Note

Dans l'entrée :

• La clé headers ne peut contenir que des en-têtes à valeur unique.

• La clé multiValueHeaders peut contenir des en-têtes à valeurs multiples, ainsi que des en-têtes à valeur unique.

• Si vous spécifiez des valeurs pour headers et multiValueHeaders, API Gateway les fusionne en une seule liste. Si la même paire clé-valeur est spécifiée dans les deux, seules les valeurs de multiValueHeaders s'afficheront dans la liste fusionnée.

Dans l'entrée de la fonction Lambda du backend, l'objet requestContext est une association de paires clé/valeur. Dans chaque paire, la clé est le nom d'une propriété de la variable $context et la valeur est la valeur de cette propriété. API Gateway peut ajouter de nouvelles clés au mappage.

D'après les fonctions activées, le mappage requestContext peut varier d'une API à l'autre. Ainsi, dans l'exemple précédent, puisqu'aucun type d'autorisation n'est spécifié, il n'y a aucune propriété $context.authorizer.* ou $context.identity.* présente. Lorsqu'un type d'autorisation est spécifié, API Gateway transmet les informations sur l'utilisateur autorisé au point de terminaison d'intégration dans un objet requestContext.identity, comme suit :

• Lorsque le type d'autorisation est AWS_IAM, les informations sur l'utilisateur autorisé comprennent des propriétés $context.identity.*.

• Lorsque le type d'autorisation est COGNITO_USER_POOLS (mécanisme d'autorisation Amazon Cognito), les informations sur l'utilisateur autorisé comprennent les propriétés $context.identity.cognito* et $context.authorizer.claims.*.

• Lorsque le type d'autorisation est CUSTOM (mécanisme d'autorisation Lambda), les informations sur l'utilisateur autorisé comprennent les propriétés $context.authorizer.principalId, ainsi que d'autres propriétés $context.authorizer.* applicables.

Format de sortie d'une fonction Lambda pour l'intégration proxy

Avec l'intégration de proxy Lambda, API Gateway demande à la fonction Lambda du backend de renvoyer la sortie selon le format JSON suivant :

{
    "isBase64Encoded": true|false,
    "statusCode": httpStatusCode,
    "headers": { "headerName": "headerValue", ... },
    "multiValueHeaders": { "headerName": ["headerValue", "headerValue2", ...], ... },
    "body": "..."
}

Dans la sortie :

• Les clés headers etmultiValueHeaders peuvent être non précisées si aucun en-tête de réponse supplémentaire ne doit être renvoyé.

• La clé headers ne peut contenir que des en-têtes à valeur unique.

• La clé multiValueHeaders peut contenir des en-têtes à valeurs multiples, ainsi que des en-têtes à valeur unique. Vous pouvez utiliser la clé multiValueHeaders pour spécifier l'ensemble de vos en-têtes supplémentaires, y compris n'importe quel en-tête à valeur unique.

• Si vous spécifiez des valeurs pour headers et multiValueHeaders, API Gateway les fusionne en une seule liste. Si la même paire clé-valeur est spécifiée dans les deux, seules les valeurs de multiValueHeaders s'afficheront dans la liste fusionnée.

Pour activer CORS pour l'intégration de proxy Lambda, vous devez ajouter Access-Control-Allow-Origin:domain-name à la sortie headers. domain-name peut être * pour n'importe quel nom de domaine. La sortie body est regroupée côté frontal en tant que charge utile de réponse de méthode. Si body est un blob binaire, vous pouvez l'encoder en tant que chaîne codée en Base64 en définissant isBase64Encoded sur true et en configurant */* comme un type de fichier multimédia binaire. Sinon, vous pouvez le définir sur false ou le laisser non spécifié.

Note

Pour plus d'informations sur l'activation de la prise en charge des fichiers binaires, voir Activation de la prise en charge binaire à l'aide de la console API Gateway. Pour obtenir un exemple de fonction Lambda, veuillez consulter Renvoi d'un support binaire à partir d'une intégration de proxy Lambda.

Si le format de la sortie de la fonction est différent, API Gateway renvoie une réponse d'erreur 502 Bad Gateway.

Pour renvoyer une réponse dans une fonction Lambda dans Node.js, vous pouvez utiliser des commandes telles que les suivantes :

• Pour renvoyer un résultat positif, appelez callback(null, {"statusCode": 200, "body": "results"}).

• Pour générer une exception, appelez callback(new Error('internal server error')).

• Pour une erreur côté client (par exemple, si un paramètre obligatoire est manquant), vous pouvez appeler callback(null, {"statusCode": 400, "body": "Missing parameters of ..."}) pour renvoyer l'erreur sans générer d'exception.

Dans une fonction async Lambda dans Node.js, la syntaxe équivalente serait la suivante :

• Pour renvoyer un résultat positif, appelez return {"statusCode": 200, "body": "results"}.

• Pour générer une exception, appelez throw new Error("internal server error").

• Pour une erreur côté client (par exemple, si un paramètre obligatoire est manquant), vous pouvez appeler return {"statusCode": 400, "body": "Missing parameters of ..."} pour renvoyer l'erreur sans générer d'exception.