4 ms·
Every time I look at Lambda+API Gateway for a web api, there's always been one little thing that makes things way harder than they should be. A while ago (pre
by wiredfool 10y ago
Every time I look at Lambda+API Gateway for a web api, there's always been one little thing that makes things way harder than they should be.
A while ago (pre proxy), it was nearly impossible to send back 302 redirects cleanly.
With LAMBDA_PROXY, it's not clear that you can actually return binary data through the Api Gateway. There's the undocumented isBase64Encoded parameter, but as far as I can tell, it's ignored. It doesn't trigger an error, but it doesn't decode base64 either.
Just this week I'm working on moving a static html site + a couple of dynamic urls over. I can work around the binary issue, but serving images is a solved problem in the rest of the world.
- throwaway2016a 10y agoBinary data is tricky with Lambda proxy (and by tricky I mean... I haven't gotten it to work). But I also haven't tried much. Typically best practice for me has been: - When dealing with uploads have an API call to get a pre-signed S3 upload URL - When dealing with downloads using HATEOAS and/or the Location header to send the client to S3 to grab the actual file. It requires some client-side designing around eventual consistency but it works well and is very scalable.
- breandr 10y agoYou need to specify your MIME type (most commonly, application/json) to be treated as binary (from console: API -> Binary Support). In your Lambda function: `callback(null, { body: base64EncodedBody, status: 200, headers: {}, isBase64Encoded: true })`
- wiredfool 10y agoThe mimetype of the response from lambda? Or the mimetype in the headers?