#1 - Aug. 24, 2011, 7:59 p.m.
We registered with Blizzard and started signing all of our requests with the provided public/private key, but we still ended up exceeding the daily limits. (For background, we do not run "batch" operations or crawl the armory: all armory requests are user-initiated requests to load a single character.)
Unfortunately, we have been unable to contact api support to discuss possibly raising the cap for our site -- they are probably pretty busy working on new features and the such, so I'm not too surprised. First question: is Blizzard open to discussion on increasing rate and volume limits for reputable sites that can guarantee responsible use of the API?
In the meantime, we have been using a JSONP approach: if a user asks to reload his character, we send a request right from the browser using JSONP, then send that data to our own server for processing and caching. There are a few issues with this approach though:
When using JSONP, if an error occurs, it seems that the callback is never invoked. Thus we are unable to display or respond to any of the nice error handling that Blizzard has provided. Our only recourse is to set a timeout and if it doesn't come back in say 10 seconds... throw up a generic message. Does anyone have any advice on this front?
This approach noticeably degrades the user experience, particularly over a slower internet connection such as a 3G network. Whereas before we would send just one request to our server, now we have to do 3 requests: one to our server to get the last-updated date on our cache, a second out to the armory, and a third back to our server to process the armory response.
The JSONP approach also leads to customer service issues: sometimes a user will have battle.net blocked with a script blocker, or be using a work computer that blocks game-related domains.
In summary, fundamentally the Armory API is handling the same amount of traffic using JSONP as routing it all through our own servers, so from their perspective they shouldn't "care" which way it is done. But I'm pretty flexible -- ideally we could discuss increasing the rate limit, but if that's not possible, advice on error handling with JSONP would be much appreciated!
