Closed DaveParr closed 5 years ago
Hi @DaveParr,
I already build an example on how to handle API Gateway requests: https://github.com/bakdata/aws-lambda-r-runtime/blob/master/tests/R/api.R
The key is the ...
. You also need to update the layer because the old response format with result
was unsuitable.
Perfect, I had assumed and tried ...
but this was failing in arn:aws:lambda:eu-west-2:131329294410:layer:r-runtime-3_6_0:4
, updated to arn:aws:lambda:eu-west-2:131329294410:layer:r-runtime-3_6_0:6
and it works like a charm.
In practice the call to the service is more complex than {'x':1}.
For instance
sam
has an example as follows:When this is held as a 'test' even in the console (and potentially therefore also when used in practice?) the
script.R
fails with:In some cases the structure can be predetermined, so in a toy case the
increment
function from the example becomes:However there is no guarantee in lambda of the source of the json, or really it's wider structure. It could need to accept multiple trigger patterns. Is it correct to fail if the json isn't exactly what is expected, even if all the cruft (
resource, path, httpMethod, isBase64Encoded, queryStringParameters, pathParameters, stageVariables, headers, requestContext
) has no bearing on the calculation? Is it possible to absorb these unimportant arguments in the event currently?