CODEWITHSUNDEEP
asp.netcaching.net-coreaws-lambdaaws-api-gateway
MattS
MattS

Reputation: 31

AWS Lambda, Caching {proxy+}

Simple ASP.Net AWS Lambda is uploaded and functioning with several gets like:

{proxy+}

api/foo/bar?filter=value

api/foo/barlist?limit=value

with paths tested in Postman as: //#####.execute-api.us-west-2.amazonaws.com/Prod/{proxy+}

Now want to enable API caching but when doing so only the first api call gets cached and all other calls now incorrectly return the first cached value.

ie //#####.execute-api.us-west-2.amazonaws.com/Prod/api/foo/bar?filter=value == //#####.execute-api.us-west-2.amazonaws.com/Prod/api/foo/barlist?limit=value; In terms of the cache these are return the same but shouldn't be.

How do you setup the caching in APIGateway to correctly see these as different requests per both path and query?

Upvotes: 1

Views: 313

Answers (1)

Tom
Tom

Reputation: 3656

I believe you can't use {proxy+} because that is a resource/integration itself and that is where the caching is getting applied. Or you can (because you can cache any integration), but you get the result you're getting.

Note: I'll use the word "resource" a lot because I think of each item in API Gateway as the item in question, but I believe technically AWS documentation will say "integration" because it's not just the resource but the actual integration on said resource...And said resource has an integration and parameters or what I'll go on to call query string parameters. Apologies to the terminology police.

Put another way, if you had two resources: GET foo/bar and GET foo/barlist then you'd be able to set caching on either or both. It is at this resource based level that caching exists (don't think so much as the final URL path, but the actual resource configured in API Gateway). It doesn't know to break {proxy+} out into an unlimited number of paths unfortunately. Actually it's method plus resource. So I believe you could have different cached results for GET /path and POST /path.

However. You can also choose the integration parameters as cache keys. This would mean that ?filter=value and ?limit=value would be two different cache keys with two different cached responses.

Should foo/bar and foo/barlist have the same query string parameters (and you're still using {proxy+}) then you'll run into that duplicate issue again.

So you may wish to do foo?action=bar&filter=value and foo?action=barlist&filter=value in that case.

You'll need to configure this of course, for each query string parameter. So that may also start to diminish the ease of {proxy+} catch all. Terraform.io is your friend.

This is something I wish was a bit more automatic/smarter as well. I use {proxy+} a lot and it really creates challenges for using their caching.

Upvotes: 2

Related Questions