Original Url: http://forum-en.guildwars2.com/forum/community/api/Guild-emblem-ids-string-or-numbers

JaxomNC.5381:

Hi, a recent change to v1/guild_details/emblem now returns all ids are strings instead of numbers.

Taking the example on the wiki (http://wiki.guildwars2.com/wiki/API:1/guild_details), for https://api.guildwars2.com/v1/guild_details.json?guild_id=75FD83CF-0C45-4834-BC4C-097F93A487AF , previouly we’ve had:

{
“guild_id”: “75FD83CF-0C45-4834-BC4C-097F93A487AF”,
“guild_name”: “Veterans Of Lions Arch”,
“tag”: “LA”,
“emblem”: {
“background_id”: 27,
“foreground_id”: 114,
“flags”: [],
“background_color_id”: 11,
“foreground_primary_color_id”: 584,
“foreground_secondary_color_id”: 64
}
}

Now, instead, we get:

{
“guild_id”: “75FD83CF-0C45-4834-BC4C-097F93A487AF”,
“guild_name”: “Veterans Of Lions Arch”,
“tag”: “LA”,
“emblem”: {
“background_id”: “27”,
“foreground_id”: “114”,
“flags”: [],
“background_color_id”: “11”,
“foreground_primary_color_id”: “584”,
“foreground_secondary_color_id”: “64”
}
}

All ids that were numbers are now strings. It’s probably not an issue with JavaScript but I am programming tests in Java with JSON-P where type does actually matter. So currently I am getting a lot of ClassCastExceptions because of this. Before I attempt to fix anything and use string instances all over the place: is this an intended change? Is this supposed to be permanent or is this something that was overlooked? What about other API endpoints which used to have numbers/integers for ids?

smiley.1438:

Yay, my guild is famous!

I’m pretty sure this is not intended. In fact, there have been patches which turned numerical strings into actual numbers in other endpoints (items for example).

Chokapik.3741:

In Java you should be able to use Integer.parseInt("" + i). This way it should convert strings to ints and not cause errors if i is already an integer.

JaxomNC.5381:

Thx I’ve been doing Java since ’98, parseInt() is not the issue.

The issue is that invoking jsonObject.getInt(<id>) in JSON-P raises a ClassCastException because, due to this change, the value stored for those accessors in the JsonObject is of type JsonValue.STRING instead of JsonValue.NUMBER. Thus jsonObject.getString(<id>) or jsonObject.getJsonString(<id>) needs to be called instead and then the value needs to be parsed. And, if I do the change preemptively, and later the API switches back to numbers instead of strings, I will get ClassCastException instead for the very same reason.

Lawton Campbell.8517:

JaxomNC.5381:

Before I attempt to fix anything and use string instances all over the place: is this an intended change? Is this supposed to be permanent or is this something that was overlooked? What about other API endpoints which used to have numbers/integers for ids?

This is a bug. I changed some backend pieces around and this somehow slipped through the cracks; I’ll try to get this fixed on live today.

Lawton Campbell.8517:

This should be fixed on live.

JaxomNC.5381:

Thx, it’s working ok again now.