CODEWITHSUNDEEP
aws-api-gateway
hirenj
hirenj

Reputation: 125

Manipulating path mapping in AWS API gateway integration

I would like to modify an url parameter /resource/{VaRiAbLe} in an API gateway to S3 mapping so that it actually points to /my-bucket/{variable}. That is, it accepts mixed-case input, and maps it to a lower-case name. Mapping path variables is relatively simple enough to S3 integrations, but I can't seem to get a lower-case mapping working.

Reading through the documentation for mapping parameters, it looks like the path parameters are simple string values (and not templated values), and so defining a mapping as method.request.path.variable.toLowerCase() won't work.

Does anyone have any ideas how to implement this mapping?

Update using Orchestrated calls

Following the info from Jack, I figured I should try doing the orchestrated call, since the traffic volume is low enough that I am sure that I won't be able to keep the lambda hot.

As a proof of concept, I added two methods to my resource (sitting at /resource/{variable} - GET and POST. The GET method chains to the POST, which does the actual retrieving of the data.

POST method configuration This is a vanilla S3 proxying method, where you set the URL Path parameter for {variable} to be method.request.body.variable.

GET method configuration This is a HTTPS proxying method. You'll need an URL for the POST method, so you'll need to deploy the API to get the URL. The only other configuration needed here is a body mapping template with content like:

{
    "variable" : "$input.params('variable').toLowerCase()",
    "something" : "$input.params('something')"
}

This should be enough to get this working.

The downside to this looks to be that I'm adding an extra method (POST) to my API for that resource that could confuse consumers of the API. I think it should be possible to make the POST on the /resource resource, which would at least make a bit more sense from an API design standpoint.

Upvotes: 3

Views: 3059

Answers (1)

jackko
jackko

Reputation: 7344

Depending on how frequently this API will be called, I'd either go with the Lambda proxy or chaining two API Gateway methods together. If the API is called frequently enough to keep a Lambda function warm (say once a minute), then go with Lambda. If not, go with the orchestrated API call.

The orchestrated API call would be interesting, I'd be happy to help with that if you have questions.

As far as I know the only S3 API for getting object data is the GET that is documented in their API reference.

Upvotes: 2

Related Questions