

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.

# Gestion des erreurs Lambda dans API Gateway
<a name="handle-errors-in-lambda-integration"></a>

 Pour les intégrations personnalisées Lambda, vous devez mapper les erreurs renvoyées par Lambda dans la réponse d'intégration à des réponses d'erreurs HTTP standard pour vos clients. Sinon, les erreurs Lambda sont renvoyées en tant que réponses `200 OK` par défaut et le résultat n'est pas intuitif pour les utilisateurs de l'API. 

 Lambda peut renvoyer deux types d'erreurs : des erreurs standard et des erreurs personnalisées. Dans votre API, vous devez les gérer différemment. 

 Avec l'intégration de proxy Lambda, Lambda doit renvoyer une sortie au format suivant : 

```
{
  "isBase64Encoded" : "boolean",
  "statusCode": "number",
  "headers": { ... },
  "body": "JSON string"
}
```

Dans cette sortie, `statusCode` est généralement `4XX` pour une erreur de client et `5XX` pour une erreur de serveur. API Gateway traite ces erreurs en mappant l'erreur Lambda à une réponse d'erreur HTTP, en fonction du code `statusCode` spécifié. Pour qu'API Gateway transmette le type d'erreur, (par exemple `InvalidParameterException`), dans le cadre de la réponse au client, la fonction Lambda doit inclure un en-tête (par exemple, `"X-Amzn-ErrorType":"InvalidParameterException"`) dans la propriété `headers`. 

**Topics**
+ [Gestion des erreurs Lambda standard dans API Gateway](#handle-standard-errors-in-lambda-integration)
+ [Gestion des erreurs Lambda personnalisées dans API Gateway](#handle-custom-errors-in-lambda-integration)

## Gestion des erreurs Lambda standard dans API Gateway
<a name="handle-standard-errors-in-lambda-integration"></a>

Le format AWS Lambda d'une erreur standard est le suivant :

```
{
  "errorMessage": "<replaceable>string</replaceable>",
  "errorType": "<replaceable>string</replaceable>",
  "stackTrace": [
    "<replaceable>string</replaceable>",
    ...
  ]
}
```

 Ici, `errorMessage` est une expression de chaîne de l'erreur. `errorType` est un type d'erreur ou d'exception dépendant du langage. `stackTrace` est une liste d'expressions de chaîne montrant la trace de la pile conduisant à l'apparition de l'erreur. 

 Par exemple, considérez la fonction Lambda JavaScript (Node.js) suivante. 

```
export const handler = function(event, context, callback) {
    callback(new Error("Malformed input ..."));
};
```

Cette fonction renvoie l'erreur Lambda standard suivante, contenant `Malformed input ...` comme message d'erreur :

```
{
  "errorMessage": "Malformed input ...",
  "errorType": "Error",
  "stackTrace": [
    "export const handler (/var/task/index.js:3:14)"
  ]
}
```

 De même, examinez la fonction Lambda Python suivante qui génère une `Exception` avec le même message d'erreur `Malformed input ...`. 

```
def lambda_handler(event, context):
    raise Exception('Malformed input ...')
```

 Cette fonction renvoie l'erreur Lambda standard suivante : 

```
{
  "stackTrace": [
    [
      "/var/task/lambda_function.py",
      3,
      "lambda_handler",
      "raise Exception('Malformed input ...')"
    ]
  ],
  "errorType": "Exception",
  "errorMessage": "Malformed input ..."
}
```

 Notez que les valeurs de propriété `errorType` et `stackTrace` sont dépendantes du langage. L'erreur standard s'applique également à n'importe quel objet d'erreur qui est une extension de l'objet `Error` ou une sous-classe de la classe `Exception`. 

 Pour mapper l'erreur Lambda standard à une réponse de méthode, vous devez d'abord décider d'un code de statut HTTP pour une erreur Lambda donnée. Vous définissez ensuite un modèle d'expression régulière sur la `[selectionPattern](https://docs.aws.amazon.com/apigateway/latest/api/API_IntegrationResponse.html#selectionPattern)` propriété du code d'état HTTP [IntegrationResponse](https://docs.aws.amazon.com/apigateway/latest/api/API_IntegrationResponse.html)associé au code d'état HTTP donné. Dans la console API Gateway, ce `selectionPattern` est désigné comme **Expressions régulières de l’erreur Lambda** dans la section **Réponse d’intégration** sous chaque réponse d’intégration.

**Note**  
API Gateway utilise des expressions régulières de type modèle Java pour le mappage de réponse. Pour plus d’informations, consultez la section [Modèles](https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html) dans la documentation Oracle.

 Par exemple, utilisez ce qui suit [put-integration-response](https://docs.aws.amazon.com/cli/latest/reference/apigateway/put-integration-response.html)pour configurer une nouvelle `selectionPattern` expression : 

```
aws apigateway put-integration-response --rest-api-id z0vprf0mdh --resource-id x3o5ih --http-method GET --status-code 400 --selection-pattern "Malformed.*" --region us-west-2
```

 Veillez également à configurer le code d'erreur correspondant (`400`) dans la [réponse de méthode](api-gateway-method-settings-method-response.md#setup-method-response-status-code). Sinon, API Gateway renvoie une réponse d'erreur de configuration non valide lors de l'exécution. 

**Note**  
 Lors de l'exécution, API Gateway met en correspondance le message `errorMessage` de l'erreur Lambda avec le modèle de l'expression régulière sur la propriété `selectionPattern`. S'il existe une correspondance, API Gateway renvoie l'erreur Lambda en tant que réponse HTTP du code de statut HTTP correspondant. S'il n'existe pas de correspondance, API Gateway renvoie l'erreur sous la forme d'une réponse par défaut ou émet une exception de configuration non valide si aucune réponse par défaut n'est configurée.   
 La définition de la valeur `selectionPattern` sur `.*` pour une réponse donnée revient à réinitialiser cette réponse comme la réponse par défaut. En effet, un tel modèle de sélection correspond à tous les messages d'erreur, y compris null, c'est-à-dire, tout message d'erreur non spécifié. Le mappage résultant remplace le mappage par défaut. Si vous utilisez `.+` comme modèle de sélection pour filtrer les réponses, il se peut qu’il ne corresponde pas à une réponse contenant un caractère de nouvelle ligne (`\n`).

 Pour mettre à jour une `selectionPattern` valeur existante à l'aide de AWS CLI, appelez l'[update-integration-response](https://docs.aws.amazon.com/cli/latest/reference/apigateway/update-integration-response.html)opération pour remplacer la valeur du `/selectionPattern` chemin par l'expression regex spécifiée du `Malformed*` modèle. 



Pour définir l’expression `selectionPattern` à l’aide de la console API Gateway, saisissez l’expression dans la zone de texte **Expressions régulières de l’erreur Lambda** lors de la configuration ou de la mise à jour d’une réponse d’intégration d’un code de statut HTTP spécifié. 

## Gestion des erreurs Lambda personnalisées dans API Gateway
<a name="handle-custom-errors-in-lambda-integration"></a>

 Au lieu de l'erreur standard décrite dans la section précédente, vous AWS Lambda permet de renvoyer un objet d'erreur personnalisé sous forme de chaîne JSON. L'erreur peut être n'importe quel objet JSON valide. Par exemple, la fonction Lambda JavaScript (Node.js) suivante renvoie une erreur personnalisée : 

```
export const handler = (event, context, callback) => {
    ...
    // Error caught here:
    var myErrorObj = {
        errorType : "InternalServerError",
        httpStatus : 500,
        requestId : context.awsRequestId,
        trace : {
            "function": "abc()",
            "line": 123,
            "file": "abc.js"
        }
    }
    callback(JSON.stringify(myErrorObj));
};
```

 Vous devez transformer l'objet `myErrorObj` en chaîne JSON avant d'appeler `callback` pour quitter la fonction. Sinon, `myErrorObj` est renvoyé sous la forme d'une chaîne `"[object Object]"`. Lorsqu'une méthode de votre API est intégrée à la fonction Lambda précédente, API Gateway reçoit une réponse d'intégration avec la charge utile suivante : 

```
{
    "errorMessage": "{\"errorType\":\"InternalServerError\",\"httpStatus\":500,\"requestId\":\"e5849002-39a0-11e7-a419-5bb5807c9fb2\",\"trace\":{\"function\":\"abc()\",\"line\":123,\"file\":\"abc.js\"}}"
}
```

 Comme avec toute réponse d'intégration, vous pouvez transmettre cette réponse d'erreur telle quelle à la réponse de méthode. Vous pouvez aussi avoir un modèle de mappage pour transformer la charge utile en un autre format. Prenons l'exemple du modèle de mappage de corps suivant pour une réponse de méthode d'un code du statut `500` : 

```
{
    errorMessage: $input.path('$.errorMessage');
}
```

Ce modèle convertit le corps de réponse d'intégration qui contient la chaîne JSON d'erreur personnalisée en le corps de réponse de méthode suivant. Ce corps de réponse de méthode contient l'objet JSON d'erreur personnalisée : 

```
{
    "errorMessage" : {
        errorType : "InternalServerError",
        httpStatus : 500,
        requestId : context.awsRequestId,
        trace : {
            "function": "abc()",
            "line": 123,
            "file": "abc.js"
        }
    }
};
```

 En fonction des exigences de votre API, il se peut que vous ayez besoin de transmettre tout ou partie des propriétés d'erreur personnalisée comme paramètres d'en-tête de réponse de méthode. Vous pouvez le faire en appliquant les mappages d'erreur personnalisée du corps de réponse d'intégration aux en-têtes de réponse de méthode. 

Par exemple, l'extension OpenAPI suivante définit un mappage à partir des propriétés `errorMessage.errorType`, `errorMessage.httpStatus`, `errorMessage.trace.function` et `errorMessage.trace` aux en-têtes `error_type`, `error_status`, `error_trace_function` et `error_trace`, respectivement. 

```
"x-amazon-apigateway-integration": {
    "responses": {
        "default": {
          "statusCode": "200",
          "responseParameters": {
            "method.response.header.error_trace_function": "integration.response.body.errorMessage.trace.function",
            "method.response.header.error_status": "integration.response.body.errorMessage.httpStatus",
            "method.response.header.error_type": "integration.response.body.errorMessage.errorType",
            "method.response.header.error_trace": "integration.response.body.errorMessage.trace"
          },
          ...
        }
    }
}
```

 Lors de l'exécution, API Gateway désérialise le paramètre `integration.response.body` lorsqu'il effectue les mappages d'en-tête. Toutefois, cette désérialisation s'applique uniquement aux body-to-header mappages pour les réponses d'erreur personnalisées Lambda et ne s'applique pas aux mappages utilisant. body-to-body `$input.body` Avec ces mappages custom-error-body-to -header, le client reçoit les en-têtes suivants dans le cadre de la réponse de méthode, à condition que les `error_type` en-têtes`error_status`, `error_trace``error_trace_function`, et soient déclarés dans la demande de méthode. 

```
"error_status":"500",
"error_trace":"{\"function\":\"abc()\",\"line\":123,\"file\":\"abc.js\"}",
"error_trace_function":"abc()",
"error_type":"InternalServerError"
```

La propriété `errorMessage.trace` du corps de réponse d'intégration est une propriété complexe. Elle est mappée à l'en-tête `error_trace` sous la forme d'une chaîne JSON. 