AysonCurrax.3254:

Hey guys,

I am currently working on providing an api of my own that will provide all the types (for example weight_class, damage_type, unlock_type etc.) and flags ( for example AccountBound or Offensive) that are currently in use within the official apis.

I was working on my application for a bit, and it dynamically adds new types and flags to my database if it finds any.

I figured this might be useful for you guys aswell, since i noticed that the documentation for those values was rather lackluster, so this would make things alot easier since it is bound to keep things up to date.

I will post the URL and further information here once its fully up and running.

AysonCurrax.3254:

Well, guess i ll have to delay this since i just saw that the v2/items api is out now which will probably simplify my current database structure by a longshot ._.

restructure, here i come.

poke.3712:

[…]provide all the types (for example weight_class, damage_type, unlock_type etc.) and flags ( for example AccountBound or Offensive) that are currently in use within the official apis.
[…]
I figured this might be useful for you guys aswell, since i noticed that the documentation for those values was rather lackluster, so this would make things alot easier since it is bound to keep things up to date.

It’s not an API, but the documentation on v2/items lists all the possible types and flags along with a short description for what it is used for. The lists there consider all items currently available via the API, so for now it’s pretty complete

AysonCurrax.3254:

[…]provide all the types (for example weight_class, damage_type, unlock_type etc.) and flags ( for example AccountBound or Offensive) that are currently in use within the official apis.
[…]
I figured this might be useful for you guys aswell, since i noticed that the documentation for those values was rather lackluster, so this would make things alot easier since it is bound to keep things up to date.

It’s not an API, but the documentation on v2/items lists all the possible types and flags along with a short description for what it is used for. The lists there consider all items currently available via the API, so for now it’s pretty complete

I am aware of that. my point is: if you were to look at the either the v1/recipes documentation, all the types and flags listed there i added because they previously havent been documented. Providing an API that contains all of those types/flags that are currently in use would be much more helpful for people compared to a static, potentially outdated list.

Hope that clears up what i meant with this.

PS: Added the v2/items documentation to the main page of the docu since you seem to have forgotten to do that initially and it bugged me. :p

poke.3712:

Providing an API that contains all of those types/flags that are currently in use would be much more helpful for people compared to a static, potentially outdated list.

While I agree that an outdated list is not a good thing, I disagree that there should be an API for it. Flags are usually something that is hardcoded into the logic at some point. So the set of flags is very limited, and static. And there’s no need to provide a “static documentation API”. Things like this should be in the API documentation.

An API that would provide this kind of info would in the same way require to be updated manually whenever a new flag is introduced and that has the same problems as a documentation: People forget to update it, so the resource becomes outdated. But unlike a custom API, the documentation is very easy to fix, especially by others (e.g. us, when we notice an item with a new flag).

PS: Added the v2/items documentation to the main page of the docu since you seem to have forgotten to do that initially and it bugged me. :p

Yeah, I forgot to do that. Then later remembered to do it again but forgot it again xD Thanks! ^^

StevenL.3761:

If I’m getting this right, the idea is to have a program running that periodically scans the official API for previously unknown constants. So unlike the wiki, the custom API would not require manual intervention.

AysonCurrax.3254:

If I’m getting this right, the idea is to have a program running that periodically scans the official API for previously unknown constants. So unlike the wiki, the custom API would not require manual intervention.

precisely. I figured i d make this available to other people once i got it working the way i want it, because I pretty much mapped the info from the v1 item_details api to a database and, keeping normalisation rules in mind, I would have a table that maps ids to strings of types, so to speak. thus, since i didnt want to have my application check against that table for every single item because that would be awfully slow, I first did a little prototype where i mapped everything within an ENUM, and thats the point where i noticed that the documentation on types and flags wasnt really reliable since a lot of them werent documented, such as Toy, Bundle and TwohandedToy for instance.

To this point, i have strayed from the ENUM idea and am currently getting the kinks worked out with ConcurrentCollections because I have 4 parallel threads firing away at the API for speed reasons.

That is for the v1 api though. The v2 might be a little more handy due to it letting you grab all the info you need faster and more efficient, which will also make testing less horrible because you dont have to wait xx hours for your application to be done with assaulting the v1 items api and checking that mess for errors along the way.

TL;DR : long story short, in the long run this will pretty much just be all values that are in my types and flags tables JSONified.

Not sure if there is a possibility to directly feed that info into the wiki while we are at it.

AysonCurrax.3254:

UPDATE: alright, it is working like a charm now. I got it working the way i want for the v1/item_details types and flags now and am currently externalizing the whole thing from my main application and putting it in a webapplication of its own so I wont be messing with anyone using it if i have to turn it off to change something in my main application. I will post the required info here later tonight and will soon add the same for the other v1 and later the v2 apis aswell, hopefully.

AysonCurrax.3254:

UPDATE:

v1 Item Types and Flags API:
http://api.gw2compendium.com/v1/item_types_and_flags.json

I will work on adding the same for the other v1 APIs and the move onto implementing the same for the v2 APIs as they come out.
I hope this might be helpful for some people.