Rate Limit Information in headers?

Other Halo API Support
1

Would anyone else be interested in having rate limit information stored in the headers of requests? This would allow applications that rely on a large flow of consuming data (such as mining) to rely less on worrying about handling rate limit errors and more on handling data.

Proposed headers:
X-343-RateLimit-Reset: Long - A millisecond representation of the time that the rate limit information is reset
X-343-RateLimit-Limit: Integer - Rate limit ceiling for the amount of requests allocated for the user in the given rate limit period
X-343-RateLimit-Remaining: Integer - Integer value of the amount of the allowed requests remaining for the user in the current rate limit period

Obviously this is less important for the current rate of 100/10 seconds, but in the future when they add multiple APIs or perhaps offer different tiers of API consumption rate it could be extremely beneficial. This is very practical and wouldn’t make much of an effort for the developers.

2

You should really be running your own rate limiter. Inspecting headers and handling 429 response codes seems like a round-about way of doing it.

I voted yes, because the headers might help - but you should know everything that comes down in those headers already.

3

> 2753093343646559;2:
> You should really be running your own rate limiter. Inspecting headers and handling 429 response codes seems like a round-about way of doing it.
>
> I voted yes, because the headers might help - but you should know everything that comes down in those headers already.

I understand the feasibility of implementing my own rate limit handling, but in the likely future I’m sure they’ll tweak some endpoints to have different requirements and limits. As of now it’s not really needed, but for futureproofing the API, it’d be handy.

4

> 2533275032665827;3:
> > 2753093343646559;2:
> > You should really be running your own rate limiter. Inspecting headers and handling 429 response codes seems like a round-about way of doing it.
> >
> > I voted yes, because the headers might help - but you should know everything that comes down in those headers already.
>
>
> I understand the feasibility of implementing my own rate limit handling, but in the likely future I’m sure they’ll tweak some endpoints to have different requirements and limits. As of now it’s not really needed, but for futureproofing the API, it’d be handy.

Yeah, you’re right. To allow your app to dynamically change it’s the only way.

Hopefully changes like that are made loud and clear before they happen.