WoWCenter.pl
wikass zabił Mythrax the Unraveler (Normal Uldir) po raz 2.     
kuturin zdobył 7th Legionnaire's Cuffs.     
Nikandra spełnił kryterium Loot 200,000 gold osiągnięcia Got My Mind On My Money.     
Tooly zdobył Fairweather Helm.     
Muattin zdobył osiągnięcie The Dirty Five.     
Yoozku zdobył Parrotfeather Cloak.     
Mlody89 zdobył Royal Apothecary Drape.     
Weakness zabił Dazar, The First King (Mythic King's Rest) po raz 6.     
liq spełnił kryterium osiągnięcia Saving for a Rainy Day.     
Osiol spełnił kryterium osiągnięcia Saving for a Rainy Day.     
Wuntu zabił Zek'voz, Herald of N'zoth (Heroic Uldir) po raz 1.     
Olsa zabił Vectis (Heroic Uldir) po raz 6.     
Sarenus spełnił kryterium osiągnięcia Saving for a Rainy Day.     
kajtasus zdobył osiągnięcie Come Sail Away.     
ossir spełnił kryterium osiągnięcia Saving for a Rainy Day.     
mcpablo spełnił kryterium Alliance players slain. osiągnięcia Frontline Slayer.     
Emmm zabił Taloc (Heroic Uldir) po raz 17.     
AsaGorth spełnił kryterium Big-Mouth Clam osiągnięcia The Oceanographer.     

Issues with High Volume Sites

blizz -> wysłany:
I am a co-creator and the main engineer for the site www.askmrrobot.com, which is a very high-volume site that allows users to load their characters from the Armory.

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!
blizz -> wysłany:
First of all, you have contacted us and we've had a pretty active thread about your application's needs and limitations. Not only that, but you were bumped into the "fansite" category of applications which receives the highest number of daily requests that we allow. You should know this, because we told you on Monday.

Second, you are using about 1% of your daily allotment. Are you sure that you are sending authenticated requests all of the time?
blizz -> wysłany:
Guys (and gals), when threads go off topic (like trying to determine the aggressiveness of a response ... or something) then I have to lock them. Please try to stay on point.