API Ratelimit Feedback

While the 100 hits per minute is an approximate number, it changes "without notice to ensure the Torn servers remain stable" (see http://api.torn.com/), is there a way to implement a rate limit feed back, letting the bot know when is the next possible request that it can send?

Edit: To make my question clearer, here is the scenario: having multiple bots running simultaneously on their own rate-limit clock can cause problems. The most extreme case is if you have 2 bots running at max speed within the rules, but ignoring each other. 100 requests per minute + 100 requests per minute will equal 200 requests per minute combined on both bots, clearly violating the API rate limit. So my request is: is there a time stamp feedback the bot can receive on API limiting? There isn't any documentation on it.

Make a function counting the API calls where every time you want to call the API you check the time.

Has 60 seconds passed -> Reset the counter

Has 60 seconds NOT passed? -> Increment the counter and if it is higher than a certain amount, dont call the API.

Our C# Wrapper implements this in this way. Feel free to check the code on Github.

https://github.com/GamingAnonymous/TornCityAPISharp/blob/master/Utils/API.cs



Specifically these lines:

44-81

Reason why I am requesting that the torn API supply the rate limit for my bot to interpret, is because we, theoretically, have infinite amount of devices accessing that specific key. And if each bot has its own rate limit, without a care of what the others are using, then its very easy to overload the server.

Realistically, I have been rate limiting with such a timer that you have suggested. But as I stated before, the rate limit can change, other bots can be using the key, ect.

You cant control what other scripts or applications are doing so just make sure you arent doing more requests than needed.

I dont get why you are worrying about a players API key so bad as they should know the risks and consequences of using too many requests.

I doubt any time soon we will be able to track an API keys available requests.



Tl;DR Stop worrying, like wtf, players know the risks.

Players know the risks, sure (or maybe), but I see the motivation of creating stable tools with some error handling (or more: error prevention).

I think as developers, we should worry about the requests we do with API keys, so this is on my opinion a valid question and would be a useful addition in the API handling.

#justmy2cents :-)

/by

As Byrod pointed out, I am looking at this from a developer's point of view.

And I am not?

While I have not created any formal applications using the API I would like to think that you wouldnt need to spam it too much so that you lock a key. It should be more then enough requests for a user. As mentioned before just track your own API calls and make sure you arent doing something stupid like updating every second. I know full well that most other applications have a adjustable variable so that the USER can adjust how often its contacts the API, this way there much less of a chance of overloading their key.

Yes we don't know exactly what other tools do and where a user uses the API key. But wouldn't it be nice to prevent by design that tools do not block the API key?

I can imagine several use cases where multiple calls per minute could be interesting (like getting information about your own faction members, as one example).

You can't control what others scripts do, this is true. But the API response could maybe give at least a hint ;-) That's all echoblast53 is asking for. I am not saying that the suggested way is the golden solution for this purpose, but just saying 'we don't need something like this, it's the users risk' is too simple in my opinion.

I still think: error prevention > error handling. At least this should be a developers motivation.

/by

... so apparently I have a worst time explaining. See Byroid's comment XD



And I also agree: error prevention trumps error handling. Which is why I deleted 5 other custom bots running on a 1 minute interval each to give my 2 second bot and my 30 second bot some breathing room.

Also, the timer you refer to doesn't have to make 1 api call. 1 program probably has to make 2-5 calls per cycle to get its info, or maybe 2 calls cycling at a fast rate, with 3 more low priority calls cycling on a very long delay. With multiple programs that don't share the information across the board, it can get hectic on usage real quickly, resulting in maybe 3 maximum users.





The following is probably the most relevant to respond to you Gaming

I am not referring to spamming at 500 milliseconds. I am just referring to the fact that when you add bots to your api access, you probably will forget that you have it accessing. So when it comes time to add more applications, it would be nice to use the ratelimit info to restrict the bots, instead of going to the drawing board, counting how many bots you have, how many seconds u can spare, and readjusting the bots accordingly.

Why are you so against having remaining calls displayed? Lol

I agree with Byrod. It would be a nice addition. As a developer, you should be responsible with keys that players have trusted you with.

I mostly just wanted to dig a little deeper into reasoning.

I completely agree it would be nice, im just being stubborn lol and cant see it providing much use. A poll or survey would be cool to see how many plugins/applications people use which take advantage of the API. If you guys know of one, then feel free to link it.

Lol, don't worry GamingAnonymous, even I don't know of 100 torn API applications. Most of my problems come about when I create and forget bots.

then you should make server side requests, each one storing the API key usage in the database so that any device can track when the API key has reached the limit.

I have thought about it. But now you are restricting your used programs to only your custom programs. Meanwhile, programs like DocTorn won't be on this system.

Or something close to it. At least it is better than nothing.

well, drn says how much it updates

so

Torn API does exactly this: every time you do an API request, Torn keeps track of the number of requests and their date/time (and stores them in a database I guess).

This doesn't work.

Consider:

- API req.

- Wait 59 seconds.

- Make 90 API reqs

- Wait 1 second.

- Make 90 API reqs.



Under your model, this works fine, but it clearly does 180 reqs in

The only way to properly do this is to store date-time stamps of each request.

Holy moly is that an awful example.

Firstly, as a responsible developer no one in their right mind would use 180 requests in 2 seconds. You should try and spread out the requests.

Also, I think you missed the point a bit, you also keep track of how many requests are happening and if it is too many, then dont allow it and probably display a message telling the user to slow down.

Now I suggest you take a quick peek at the source code for TornCityAPISharp and youll very quickly see we implement this very technique.

disliked for being a twat rather than nicely suggesting / discussing :p

Its true and im sorry,

First 3 bits are legit, I will edit out the rest though. A little stressed lately and I apologise for being unreasonable at that point.