0

My REST API occasionally needs to return a 413 'Payload too large' response.

As context: I use AWS with API Gateway and Lambda. Lambda has a maximum payload of 6Mb. Sometimes - less than 0.1% of requests - the payload is greater that 6Mb and my API returns a 413 status.

The way I deal with this is to provide an alternative way to request the data from the API - as a URL with the URL linked to the data stored as a json file on S3. The S3 is in a bucket with a lifecycle rule that automatically deletes the file after a short period.

This works OK, but has the unsatisfying characteristic that a large payload request results in the client making 3 separate calls:

  1. Make a standard request to the API and receive the 413 response
  2. Make a second request to the API for the data stored at an S3 URL. I use an asURL=true parameter in the GET request for this.
  3. Make a third request to retrieve the data from the S3 bucket

An alternative I'm considering is embedding the S3 URL in the 413 response. For example, embedding it in a custom header. This would avoid the need for the second call.

I could also change the approach so that every request is returned as an S3 URL but then 99.9% of the requests would unnecessarily make 2 calls rather than just 1.

Is there a best practice here, or equally, bad practices to avoid?

CharlesA
  • 4,260
  • 2
  • 25
  • 31

1 Answers1

0

I would do the way you said - embed S3 URL in the 413 response. Then the responsibility of recovering from 413 will be on the client to check for 413 in the response and call s3. If the consumer is internal then it would be ok. It could be an inconvenience if the consumer is external.

Salim
  • 2,046
  • 12
  • 13