Rate limiting and API keys
poke.3712:
Hey first of all: Thanks! The release of an official API is really awesome news, and I’m very excited about all the possible things that come out with these things now.
However I would really suggest you to rate limit the API as quickly as possible and get some API key mechanism out there. Otherwise I can already see the services being DDoS’ed or simply die out because of too many API requests—and I really don’t want that to happen. Introducing a rate limit will make developers to use the API in a more deliberate manner and prevent those things before they happen.
Cliff Spradlin.3512:
Hi,
Thanks for your suggestions.
I agree that API keys and rate limiting are important when accessing services that have limited resources.
The APIs being released today were specifically designed to handle high amounts of concurrency and utilization, and so for these APIs we feel like we don’t need to implement strong controls. That said, we’re closely monitoring usage, and if we need to we may implement stronger rate limiting.
We are working on more fine-grained rate limiting systems like you describe for future APIs; some of the ones we are considering would definitely require stronger limits.
sebrandon.2835:
So excited, I’ve already started development on a new Android application. I would really love to see an API for the Daily’s and Monthly’s so I could dynamically remind people that events are going on that pertain to available Daily events, for example.
kaspi.7164:
Do I read it correctly as “we don’t have api limits that you can break if you don’t specifically try to DoS us”? Would that mean that if I ran a script checking event states 24/7 each 30s I will not hit an API limit for the time being?
I guess you already have some API limitations mechanisms ready. How will the endpoint behave if we reach the limit? Request time out?
It would be nice if we’d be able to scale the frequency of our requests depending on the endpoint load.
Healix.5819:
They could reduce a lot of calls by adding a pre-event active state. Due to the inconsistency of event states, the best method is to basically look up the state of all events in the chain or the entire map.
Do they really not care how many calls you’re making though? I’m gathering accurate timings by polling around 30 events on about 15 servers, which is roughly about 10 calls per second (it would only be 2 per second if I didn’t have to lookup pre-events). Other pages of the gw2 domain are purposely limited, resulting in internal server errors when you make too many requests.
kaspi.7164:
Yes, it seems silly, but they might just want to see how big of a hit is the API going to be for their infrastructure. They are probably just gathering intel of how much data per second the community wants to get.
My bet is we’ll see some limits very soon, also owing of the people who are not careful with their coding. In fact, I would like to see some limits for this very reason asap.
My plan was getting WvW updates somewhere in the interval of 5 to 30s. From what I see, MOS updates their live map every 30s, but the log shows different increments for actions than 30s, which points towards more frequent API calls.
Terrasque.8735:
Actually, if properly and cleverly cached, they can probably squirt out answers to several thousand requests per second..