World of Warcraft Community API Migration

API Discussion
20

So… I bit the bullet (Yeah I know. Bad saying is bad) and rewrote my script to do this.

I saved about 4 seconds on the execution time.

Not much time saving BUT I did write a more efficient way to do the calls. One that will hopefully allow me to expand it later without gaining too much on execution time.

Thanks for the suggestion.

21

In the Profile API I’m seeing a few different things / missing information:

In the Characters Pets Collection Summary there’s no unique identifier for pets (as you can have up to 3 of each) to keep similar pets apart. In the Community API there’s a battlePetGuid that is unique for each pet.

The Characters Mounts Collection Summary seems to return all mounts (on an account?) that a character has, not just the ones that can be used, meaning Alliance and Horde specific mounts are mixed in together. There’s also no indication in there or from the Data API (Mount Index or Mount) whether a mount if Alliance or Horde specific.

22

I’ve seen in the migration plan that you are gonna deprecate the character feed endpoint. May I ask why ? I wanted to use it.
Thanks,
Genpa

23

Erorus:
The greatest discrepancy I see right away is how the Game Data API has a dearth of item data compared to the Community API. It’s most pronounced in our loss of item stats, bonus/context data, etc. Example:
/data/wow/item/141423 vs /wow/item/141423?bl=41,1562,1808,3573

Thanks for bringing this up. You are correct - the item data in Game Data API at /data/wow/item/{id} does not support the additional bonus list and creation context data. This is a gap we have identified internally, and there are ongoing discussions occurring, but we do not have any information to share at this time.

Any update on this as this is affecting a website I am currently building and have been holding out for an answer… With approximately month to go on turning off the old api we should have an answer by now…

Thanks in advance!

24

Probably a small point in the bigger scheme of things, but I wish the achievement index or at minimum the achievement category included basic properties like points and description.

I know modern hardware can keep up but emotionally I just do not feel good about having to make 4,700 queries to populate a basic achievements table (plus having to code for the possibility of partial data as the process plays out.)

25

First of all: thanks to everyone for providing feedback! We truly, sincerely appreciate it. Hitting a number of points below.

Linking Pets and Creatures

We have plans to add this information for pets in the Game Data API to reach parity with the Community API.

Realm Data

I’m not sure I understand your concern here. Could you elaborate? (What is the “realm localization information” that you’re using to determine which localized name to show? The localized realm names returned with the Realm Index are intended to be tied to the user’s language regardless of the locale associated with the realm.)

This is correct – in some cases, the slug names have changed from their equivalents in the Community API.

Pet GUIDs

We’ve put a bug into our backlog to track this.

Mount Factions

The former is working as intended – the Character Mounts Collection Summary endpoint returns all mounts that you would see if you were to open your mounts collection in-game. This includes Alliance and Horde specific mounts. However, the latter is a bug – the Mount endpoint should identify whether a mount is Alliance or Horde specific. We’ve put a bug in our backlog to track this.

Item Bonus List and Creation Context

Unfortunately, we do not expect to have a replacement for this by the time the Community API is turned off. We do hear your feedback, though – and even after Community API is turned off, our goal is to reach feature parity for this.

Increased API Request Count

I don’t have any meaningful updates here, but I do want to say that we hear you and that we’re discussing options.

1 Like
26

What about the Auction House Data? Now in “Game Data API Migration” written “PLANNED\TBD”.
There is not much time left until December 16.

1 Like
27

tbh this deadline really sucks. especially when not all resources are even finished. I really need the user characters, but that’s still in progress.

28

I am really glad to hear that you are aware of concerns on increased API call count as a result of retiring community API.

Please consider it as a not only poorly chosen, but also poorly worded example for a failed attempt at trying to point out current game data API index functions provide very little information with respect to community API master list functions.

Let me try again,

Granted, I am not a big fan of designing public APIs only as micro-service like end points so clients have to make lots of individual function calls over internet to gather all required information. So I am somewhat biased.

I understand that you are providing a platform for game related information and cannot know ahead of time, what kind of information your clients need and want for their applications. Also it may be very costly and detrimental for system performance to gather all current index and child data related to a function call for frequently changing (thus cannot be cached) data.

However, in my opinion, it would be preferable to provide master list functions at least for static or semi static data (like realm list, item list, pet list, item classes etc) in addition to current functions. By “master list function” I mean collecting and caching data on server side and returning whole list (with all information that can be gathered from all kinds of queries you can do for that particular subject) to clients with a single call.

Regards,

29

It seems to me you actually want data dumps instead of an API. If index functions returned ALL data for each individual item some of them like items would have large sizes.

As you can see here https://gitlab.com/francisschiavo/wow-data/blob/master/items/items.csv all items for all locales is nearly 45MB of data. While this could work if you wanna update a complete database, it does not make sense for people who need to consume the API on demand.

30

I don’t understand? Are you saying there are apps that, in the name of being on demand, start every user request by querying for the static index that changes once per patch? If so I’d see why that index needs to be as lightweight as possible but that also seems crazy to me.

Meanwhile I don’t think anyone is requesting the individual record APIs go away so those are available for on demand consumption in any case.

I’d go on more but I’ve already bit the bullet and changed things over to where I just crawl the index with the many thousands of queries it takes to seed the basic tables I’m interested in. It’s done and it works and it’s not even that slow, but it still feels emotionally wrong when I happen to dwell on it, especially when the difference between the index and the full record is like 2 short string properties vs. 6 short string properties.

31

No, I hope nobody is doing that. What I mean is for data like that instead of an endpoint index, it is better a data dump link, similar to the current AH endpoint. It doesn’t give you every entry as a json object, but instead a link to a data dump file with everything.

1 Like
32

I am concerned with what I just had to go through to get a realm-id (slug) since we will no longer be able use the string :realmname.

Code

function milliseconds() 
{
    $mt = explode(' ', microtime());
    return ((int)$mt[1]) * 1000 + ((int)round($mt[0] * 1000));
}
$start = milliseconds();
$count = 0;
$response = 1;
foreach (json_decode($apiClient->execute("https://us.api.blizzard.com/data/wow/connected-realm/index?namespace=dynamic-us&locale=en_US", $response))->connected_realms as $endpoint)
{
    $count++;
    if (json_decode($apiClient->execute($endpoint->href . "&locale=en_US", $response))->realms[0]->slug == "moon-guard")
    {
    	echo $endpoint->href;
    	break;
    }
}

$stop = milliseconds() - $start;
printf("<br>Exec time: %sms<br>Iterations: %d", $stop, $count);

output
https://us.api.blizzard.com/data/wow/connected-realm/3675?namespace=dynamic-us
Exec time: 22369ms
Iterations: 103

It took me 22 seconds and 104 API calls in total just to get the ID. That is definitely not going to scale.

I feel that the “Connected Realms Index” should return a single layered json key value hash table of {‘id’:‘realmname’} if we are to use the id. I do not need a list of endpoints when the documentation clearly shows how to get from a singular realm id.

Also, can you not mix datatypes in the response. Would be nice to get a string i can json_decode and have as a multilayered associative array. Not an object of an array of an object of an array…

33

Maybe I’m missing something, but it sounds like you want the realmSlug from the realmname. This information can be derived from the realms index /data/wow/realm/index. Getting the data from that endpoint takes me around 1900ms, but I can then cache the resultant JSON and do lookups for the rest of my needs (my app is desktop so I cache almost all the non-character data to filesystem, YMMV).

I’m using PowerShell, but I think the gist of what I’m doing for the lookup is readable even if you don’t do PS (the final $slug can be read as return $slug…it’s a PS shorthand to just list the object):

<#
.SYNOPSIS
    Maps a realm name (or id) to the realmSlug
#>
function Get-RealmSlug {
    [CmdletBinding(DefaultParameterSetName = 'name')]
    param (
        [Parameter(Mandatory, ParameterSetName = 'name', Position = 0)]
        $Name,
        [Parameter(Mandatory, ParameterSetName = 'id')]
        $Id
    )

    $realmsIndex = Get-WowData -Api RealmsIndex | Select-Object -ExpandProperty realms
    if (-not $realmsIndex) {
        Write-Warning 'Could not retrieve Realms Index.'
        return
    }
    
    switch ($PSCmdlet.ParameterSetName) {
        'name' { $slug = $realmsIndex | where name -eq $Name | select -ExpandProperty slug }
        'id' { $slug = $realmsIndex | where id -eq $Id | select -ExpandProperty slug }
        default { throw 'Internal script error in Get-RealmSlug' }
    }

    if (-not $slug) {
        Write-Warning "Realms index did not have a value matching $($PSCmdlet.ParameterSetName):${Name}${Id}"
    }

    $slug
}
1 Like
34

I would like to know about this too. The lack of auction data and character professions worries me.

This deprecation feels kind of rushed, as all of the old community API is not even implemented in the new one. IMO, they should not have set this deadline until everything was in place.

They should at least allow the old ones stay up until they are replaced by a new endpoint.

35

Hello @Araspir,

Could you provide an update as to if the Community API will truly be turned off on Dec 16th?

The 2 endpoints I am using are not yet in AVAILABLE status. Namely:

  • Character Statistics PLANNED /wow/character/:realm/:characterName?fields=statistics TBD
  • User Characters IN PROGRESS /wow/user/characters /profile/{account-id}/wow

Any additional information you could provide would help planning on my end as we are planning to release our product between Dec 13 - Dec 20

Thanks!

36

Once again: thanks so much for the feedback, y’all! We’re continuing to parse this information and discuss solutions.

In the meantime, we have an important announcement regarding the migration deadline: WoW Community API Migration Deadline Extension

39

As of 2020-03-16T19:00:00Z, the World of Warcraft Community API has been turned off. For more information, check out the thread here: WoW Community API Turned Off