I was wondering if the scenario of a server based app that lives in a hosted environment, where a single IP can be shared by many web sites.
As I understand the rate-limit as it stands, every site on the shared host IP, regardless of api key, will be sharing the same rate-limit of 10,000 per site per day.
I can see two possible ways to remedy this problem, if in fact it does exist:
- use the referrer authority, if it exists
- remove the ip from the equation and limit per key
Thoughts?
We have an answer but let me draw a silly picture to make the story perfectly clear.
George decides to switch over to asp/c# so he can use the fantabulous soapi library and buys a shrared hosting account on discountasp.net.
By the luck of the draw, his domain, with his exponentially growing list of rate-limit gobbling apps, gets placed on the same shared host that my slowly growing list of request hungry apps are living on.
My cron kicks off in the middle of the day and fails.
Why? because although George is using a different API key, we share the same IP, so when I kick off expecting to get a good 5000 requests in over the next 3 or 4 hours, they are already used up.
The explained solution is to get a rate-limit increase or other allowance.
But with the current setup, there is still no segregation between the request volume of the two completely unrelated keys. So any rate increase is still shared by George and I and if the count comes up short and one of our apps breaks, who to complain to and with what metrics?
The reason this seems to be an issue to me is that there are subjective conditions that must be met to warrant any kind of rate-limit adjustment.
So I guess we will just have to keep an eye on our rate-limits and be vigilant for inadvertent usurpation and revisit the issue then.
Seems to me that using the TDL and IP of the request source, if it is available, would be one way to eliminate this problem. I have not explored the technical details of this but it might be worth exploring.