API v2 items endpoint inconsistencies
damnwidget.9301:
I have found some inconsistencies in the v2 of the API for the items endpoint. In the infusion slos subobject one of the possible values is flags that is an array of strings but in the description of the field we can find this
flags (array of strings) – Infusion slot type of infusion upgrades. The array contains a maximum of one value.
If the array can contain only one value, then, why to use an array in first instance?
Then the different values for this field are:
- Defense
- Ofense
- Utility
- An empty array means an agony infusion slot. (wat?)
This seems to be pretty inconsistent, is this object design definitive or may it change in the future?
A part from that, in the infix upgrade subobject the description for the skill_id in the buff object is that it is a string but it is a number.
Thank you
Aralicia.6157:
If the array can contain only one value, then, why to use an array in first instance?
Probably because the API mostly expose the inner game structure, and that, at some point, the possibility of multiple infusion slots was considered. Thus, the use of an array “just in case”.
Then the different values for this field are:
- Defense
- Ofense
- Utility
- An empty array means an agony infusion slot. (wat?)
I’ve got nothing, except maybe that it may be due to the fact that they reused for the ascended inscription a previous “agony” slot that was a bool ? maybe ?
Trying to explain some of those things from an outsider perspective is a bit like doing digital archeology.
Lawton Campbell.8517:
I was actually looking at this recently — the empty string should be fixed in the next patch. There was a missing serialization for the agony enumeration value.
As for the array — it was probably just in case? The data is structured to theoretically support it if it turned out to be something we wanted to do. There’s a lot of cases like this, actually.