The header Retry-After is extremely useful, since it lets users take advantage of the 'Leaky-bucket' type of limits we have. However, in order to get this header, you must trigger a 429 error.
In practice, a client of the SQL API is going to look at two headers:
Carto-Rate-Limit-Remaining, to know if they have any remaining requests
Retry-After, to set up a timer to start firing requests.
As the API stands right now, when you get Carto-Rate-Limit-Remaining: 0, you have to make another request (which you know is going to fail), to trigger the error, get the Retry-After and know exactly how much you have to wait.
What would be ideal is to return the Retry-After header when Carto-Rate-Limit-Remaining is 0, as well as on 429 errors.
rafatower
commented
4 years ago
The header
Retry-Afteris extremely useful, since it lets users take advantage of the 'Leaky-bucket' type of limits we have. However, in order to get this header, you must trigger a 429 error.In practice, a client of the SQL API is going to look at two headers:
As the API stands right now, when you get
Carto-Rate-Limit-Remaining: 0, you have to make another request (which you know is going to fail), to trigger the error, get theRetry-Afterand know exactly how much you have to wait.What would be ideal is to return the
Retry-Afterheader whenCarto-Rate-Limit-Remainingis 0, as well as on 429 errors.