Est-il un moyen de changer les codes d'état http retourné par Amazon API Gateway?

Voici le moyen le plus rapide pour retourner sur les Codes d'État HTTP et une coutume errorMessage:

Dans la Passerelle API tableau de bord, procédez de la manière suivante:

1. Dans le méthode pour votre ressources, cliquez sur méthode de réponse
2. Dans le d'État HTTP tableau, cliquez sur ajouter une réponse et ajouter dans chaque Code d'État HTTP que vous souhaitez utiliser.
3. Dans le méthode pour votre ressources, cliquez sur intégration réponse

4. Ajouter un intégration réponse pour chacun des Codes d'État HTTP que vous avez créé plus tôt. Assurez-vous que entrée passthrough est cochée. Utilisation lambda erreur regex pour identifier le code d'état doit être utilisée lorsque vous retourne un message d'erreur à partir de votre fonction lambda. Par exemple:

   //Return An Error Message String In Your Lambda Function
   
   return context.fail('Bad Request: You submitted invalid input');
   
   //Here is what a Lambda Error Regex should look like.
   //Be sure to include the period and the asterisk so any text
   //after your regex is mapped to that specific HTTP Status Code
   
   Bad Request: .*
   

5. Votre Passerelle API route devrait revenir ce:

   HTTP Status Code: 400
   JSON Error Response: 
       {
           errorMessage: "Bad Request: You submitted invalid input"
       }
   

6. Je ne vois aucun moyen de copier ces paramètres et de les ré-utiliser pour les différentes méthodes, nous avons donc beaucoup ennuyeux redondant introduction manuelle à faire!

Mon Intégration des Réponses ressembler à ceci:

1) Configurer votre Passerelle API ressource à utiliser Lambda Proxy Intégration en cochant la case "Utilisation Lambda Proxy intégration" sur "l'Intégration de la Demande" de l'écran de la Passerelle API définition de la ressource. (Ou de le définir dans votre cloudformation/terraform/sans serveur/etc config)

2) Changer votre lambda code de 2 façons

• Processus entrant event (1er argument de fonction) de manière appropriée. Il n'est plus juste le strict charge utile, elle représente l'ensemble de la requête HTTP, y compris les en-têtes, de chaîne de requête, et le corps. L'échantillon ci-dessous. Le point clé est que JSON corps seront chaînes nécessitant explicite JSON.parse(event.body) appeler (ne pas oublier try/catch autour de ça). Exemple ci-dessous.
• Répondre par l'appel de la fonction de rappel avec null alors un objet de réponse que fournit le HTTP détails, y compris statusCode, body, et headers.
  • body devrait être une chaîne de caractères, donc, ne JSON.stringify(payload) que nécessaire
  • statusCode peut être un nombre
  • headers est un objet de noms d'en-tête de valeurs

Échantillon Lambda Événement Argument pour Proxy Intégration

{
    "resource": "/example-path",
    "path": "/example-path",
    "httpMethod": "POST",
    "headers": {
        "Accept": "*/*",
        "Accept-Encoding": "gzip, deflate",
        "CloudFront-Forwarded-Proto": "https",
        "CloudFront-Is-Desktop-Viewer": "true",
        "CloudFront-Is-Mobile-Viewer": "false",
        "CloudFront-Is-SmartTV-Viewer": "false",
        "CloudFront-Is-Tablet-Viewer": "false",
        "CloudFront-Viewer-Country": "US",
        "Content-Type": "application/json",
        "Host": "exampleapiid.execute-api.us-west-2.amazonaws.com",
        "User-Agent": "insomnia/4.0.12",
        "Via": "1.1 9438b4fa578cbce283b48cf092373802.cloudfront.net (CloudFront)",
        "X-Amz-Cf-Id": "oCflC0BzaPQpTF9qVddpN_-v0X57Dnu6oXTbzObgV-uU-PKP5egkFQ==",
        "X-Forwarded-For": "73.217.16.234, 216.137.42.129",
        "X-Forwarded-Port": "443",
        "X-Forwarded-Proto": "https"
    },
    "queryStringParameters": {
        "bar": "BarValue",
        "foo": "FooValue"
    },
    "pathParameters": null,
    "stageVariables": null,
    "requestContext": {
        "accountId": "666",
        "resourceId": "xyz",
        "stage": "dev",
        "requestId": "5944789f-ce00-11e6-b2a2-dfdbdba4a4ee",
        "identity": {
            "cognitoIdentityPoolId": null,
            "accountId": null,
            "cognitoIdentityId": null,
            "caller": null,
            "apiKey": null,
            "sourceIp": "73.217.16.234",
            "accessKey": null,
            "cognitoAuthenticationType": null,
            "cognitoAuthenticationProvider": null,
            "userArn": null,
            "userAgent": "insomnia/4.0.12",
            "user": null
        },
        "resourcePath": "/example-path",
        "httpMethod": "POST",
        "apiId": "exampleapiid"
    },
    "body": "{\n  \"foo\": \"FOO\",\n  \"bar\": \"BAR\",\n  \"baz\": \"BAZ\"\n}\n",
    "isBase64Encoded": false
}

Échantillon De Rappel De La Réponse De La Forme

callback(null, {
  statusCode: 409,
  body: JSON.stringify(bodyObject),
  headers: {
    'Content-Type': 'application/json'
  }
})

Notes
- Je crois que les méthodes sur context comme context.succeed() sont obsolètes. Ils ne sont plus documentés, bien qu'ils ne semblent toujours fonctionner. Je pense que le codage de la fonction de rappel de l'API est la bonne chose à aller de l'avant.

La façon la plus simple de le faire est de utilisation LAMBDA_PROXY intégration. En utilisant cette méthode, vous n'avez pas besoin de tout spécial transformations pour être mis en API Gateway pipeline.

Votre retour de l'objet devrait être similaire à l'extrait de code ci-dessous:

module.exports.lambdaHandler = (event, context, done) => {
    //...
    let response = {
        statusCode: 200, //or any other HTTP code
        headers: {       //optional
             "any-http-header" : "my custom header value"
        },
        body: JSON.stringify(payload) //data returned by the API Gateway endpoint
    };
    done(null, response); //always return as a success
};

Il comporte quelques inconvénients: comme devant être particulièrement prudent sur la gestion des erreurs, et l'accouplement votre fonction lambda à la Passerelle API point de terminaison; cela dit, si vous n'étiez pas vraiment l'intention de l'utiliser n'importe où ailleurs, il n'est pas beaucoup d'un problème.

C'est comment il est recommandé sur AWS Calculer Blog si à l'aide de la Passerelle API. Vérifier pour voir si l'intégration fonctionne avec direct Lambda invocation.

var myErrorObj = {
    errorType : "InternalServerError",
    httpStatus : 500,
    requestId : context.awsRequestId,
    message : "An unknown error has occurred. Please try again."
}
callback(JSON.stringify(myErrorObj));

Direct Lambda invocations, cela semble être la meilleure solution d'analyse sur le côté client.