Possible issue with "buff" property
noobinator.3816:
Let me start off by saying that this API is great. Thank you so much for it!
I’m in the process of writing an Android app to interact with the API and do cool things (like everyone else on this forum). Unfortunately, I’ve run into a bit of a snag. Usually, when parsing JSON, I just use Google GSON, but occasionally I run into minor issues that end up complicating things.
In particular, item_detail objects which are weapons, have a buff property (item_detail->weapon->infix_upgrade->buff). In cases where the infix_upgrade has a buff, it is a JSON object, however, if the buff does not exist, then it is a String.
For example, Item 38875 has a buff, while item 26706 does not have a buff.
This causes problems for Google GSON and possibly other parsers. So, I have a few questions:
1. Is this an actual defect that should be fixed or do I just need to use a different parser? I’ve found a work around for the time being, but I would like to not have to use it as it will slow down my app.
2. Is this going to be a recurring theme with the API (that is, objects are either present or are Strings, but are never empty or null)?
EDIT: After some more digging, it seems like this is going to be a recurring theme as I’m now running into the same problem with the infix_upgrade itself.
EDIT2: I switched over to using Jackson to parse the data into my objects, but it dislikes this “feature” too.
Cliff Spradlin.3512:
Hi,
I don’t have much experience using JSON libraries that map to strongly-typed objects. We didn’t really design the API in mind with that use-case, so I’m not surprised that there are places where it breaks or doesn’t make sense.
Is it possible for you to use a more dynamically typed parser? If so, that may save you a lot of pain in the long-term.
The buff is supposed to be ‘null’, not an empty string, but it’s getting automatically converted in a backend server to be an empty string. My goal in specifying those types of properties was to make items more self-describing, so that you didn’t have to hunt through every item to try to figure out all the possible fields.
Maybe instead, I’ll remove the ‘null’ properties from being returned at all, and instead have a list of example items that use all the possible properties, per item type. Then developers can examine that list to figure out the properties they need to support.
How does that sound?
noobinator.3816:
Cliff, thanks for the response.
At this point, I already have the parsing all figured out and working for the item_details API using Jackson. It was a bit “hacky,” but was definitely quicker than manually writing the property-by-property parser by hand. If the empty objects were returned as nulls, empty curly braces, or not at all, that would greatly simplify my code.
Also, it would be great to have sample objects that way. This would greatly simplify development.
Thanks again!
zwei.9073:
Maybe instead, I’ll remove the ‘null’ properties from being returned at all, and instead have a list of example items that use all the possible properties, per item type. Then developers can examine that list to figure out the properties they need to support.
How does that sound?
That would be incredibly helpfull and awesome