[API Suggestion] Separate Item APIs
robotempire.2451:
I’d like to suggest splitting the item APIs into discrete endpoints based on item type, e.g.
- /v1/armor/
- /v1/weapon/
- /v1/accessory/
- /v1/recipe/
etc.
At the very least, I’d like to see the /v1/items/ API expanded to allow filtering on attribute. I reckon there must be something about the data modeling on the back end that prevents it, or it’d be done already. Plus the fact that trading post search is limited such as it is speaks to the likelihood there’s some bigger data issues that need to get settled before that kind of granularity can be implemented.
Anyway, I’m sure there are limitations on what this v1 API can do based on available engineering bandwidth. It is amazing someone took the time to even do v1. I am ok with denormalizing the data in my application. I am just loading all the armor I could find into Solr here …
Thanks.
Ruhrpottpatriot.7293:
If everything goes smoothly with GW2.NET you only have to download it once every patch and then you can access and filter it as you like.
I personally don’t see a reason to change the api for that, in my opinion this is a job for the clients to do.
A reason why there is only one endnote might have something with the /v1/items node which dumps all the items ids in a big list.
robotempire.2451:
If everything goes smoothly with GW2.NET you only have to download it once every patch and then you can access and filter it as you like.
I personally don’t see a reason to change the api for that, in my opinion this is a job for the clients to do.
A reason why there is only one endnote might have something with the /v1/items node which dumps all the items ids in a big list.
I don’t develop on Windows.
Anyway, your last sentence validates my point. The API design right now forces client-side joins. In a perfect world the API would be better designed around useful resource types. In the simple case, this would be things like weapons, armor, recipes, etc., each having their own API endpoints that could be filtered separately. I’m just talking about basic discoverable API principles.
At the VERY least, the items API should work like:
- items.json returns a list of say 50 or 100 item records, with inline pagination metadata. There are lots of formats out there to do this. One is HAL-JSON, but there are many more.
- items.json?item_id=x would work as item_details.json?item_id=x works now
- Filter on attributes. For example, items.json?type=armor would get all the armor. You get the picture.
I’m positive the limiting factor at ANet for improving their APIs engineering bandwidth, not talent or whatever. This is just constructive criticism.
Alcarin.9024:
I prefer more functionality (OAuth,TP,megaserver,character,etc..) than have a better organization of the same informations.
I, as a developer, can filter or reorganize data like I want, but I cannot develop a new TP API.
A better distinction could be useful for some items (for example satchel are the same item type than loot bag, it could be usefull to separate in two type of item), but it’s not something critical, it should not reduce ArenaNet development effort on other critical API features!