RateLimit Status for V2?

[rzo1]

Hi,

in V1 there was a dedicated RateLimitStatus endpoint. I think, that were is no equivalent in V2, yet.

However, it might be worth parsing the HTTP headers mentioned in [1] and report them back, so the user can check and not hit rate limiting with an HTTP 429.

Wdyt?

[1] https://developer.twitter.com/en/docs/twitter-api/rate-limits

[redouane59]

Hey, Good idea I didn't even know that. Do you feel able to submit a pull request ? makeRequest method from AbstractRequestHelper class could maybe do that. Otherwise I'll try to check it as soon as I'll have some time.

[rzo1]

I am a bit short of time at the moment (course preparations), so if you can have a look, it would be very appreciated. Otherwise, I can come back on it in a few weeks possibily.

[jormungander]

Yes, it would be very helpful to have the 3 rate limit values from the HTTP response headers returned for every request.

[redouane59]

Feel free to submit a pull request guys :)

[jormungander]

I'll try to do it in January.

[jormungander]

Did you have any ideas for how you wanted this implemented? There's no base object to add the response header values to so they would have to be added to all the existing response objects, or else a base object created to contain the values and all the existing objects subclass from that.
Alternatively, the results from the last request to Twitter could be stored and then a call created to return them - this has much less impact to the codebase and more mimics the way V1 did it, but could have implications for multithreading.

[rzo1]

I think, that the sanest way to implement would be to return the HTTP response headers encapsulated in the related response objects. Multi-Theading is a topic and we shouldn't stick with a stateful service as the rate limits per endpoint might differ.

It would be feasable (as a first step) to add a possibility to simply retrieve all response headers. Later we could add logic to parse / interpret the RateLimit related header elements, but as they might be subject to change, it might be better to just return the headers and let the user deal with it (or provide some utility class to parse them).

I don't think, that we need to handle the RateLimit status internally, i.e. don't allow a request if the limit is exceeded. While it would be a cool feature (in the long run), we could do it in an iterative way to allow for review / enhancements.

I was thinking of:

• 1) Implement a way to retrieve the response headers (in the response object)
• 2) Add a way to parse / interpret the RateLimit Status in the API
• 3) Enhance current code base to automatically handle the RateLimit for the user or client app

1)-3) are all separate feature requests. WDYT?