Changes to API with HoT expansion?
AggieTechGuy.4901:
I have been designing a site based off the TP API for a while now, and just heard about the HoT expansion. I’m trying to decide if I should continue creating the site hoping that there are no breaking changes to the GW2 API, or wait it out.
Can we expect an API v3? Will there be any changes to the API? If there are, could those be breaking changes?
As a side note, I think it would be awesome if those OAuth features that were mentioned previously in this forum came out
.
StevenL.3761:
Depends on what you consider to be a breaking change. I consider adding new types of data structure to be a breaking change. By data structure type, I mean any object with a ‘type’ discriminator field, and a string constant value to indicate the actual type contained within the data structure.
{
"type": "constant_value"
}
Some examples…
We already know that there will be a new competitive game type. For the items API, that means that all items will have their ‘game_types’ array updated to include the new game type. That could be a breaking change, depending on how you handle game_types that were previously unknown.
We also know that there will be a new borderlands map. This affects the ‘match_details.json’ API. There will be a new borderlands type for that API, and it’s not unthinkable that this map could have match_details that the other maps don’t. This is always a breaking change.
AggieTechGuy.4901:
Sorry, I’ll try to clarify what I mean by breaking changes in the context of my current project which mostly deals with the v2 Items endpoint.
At the moment, I’m getting closer to writing a js-driven tooltip that grabs an “items” information with v2 of the API. The way I have it coded now, if new item types or subtypes (like new types of weapons) follow the same conventions other items have used then it shouldn’t break. I would just need to tweak the tooltip for aesthetics.
If, however, the data structure itself changes it would break everything. As an example, if they changed the names of certain fields or flattened the infix_upgrade subobject into the item_details object, I’m sure that would break just about everyone’s projects relying on the items API. Hopefully if they decide to do that, it will be with a v3 API.
Something else to consider is what additions they will be making to the fundamental item system. For instance, they could add a new feature that allows players to place more than 1 upgrade in a piece of armor (rune + something else). Something like that may not break projects, but it could invalidate them.
Anyway, this post was me fishing for info from ANet, as I doubt there will be a flashy trailer with epic music made for API changes. Hopefully we’ll get some information before HoT is released so we can tweak / redo the projects we currently have.
Lawton Campbell.8517:
We’ll try our best to keep everything working without changes on the application end. I don’t know if there’s going to be any HoT-related changes, but there definitely are some warts I’d like to see fixed, which include:
- The “Outfit” consumable’s type is currently listed as “Unknown”.
- Boon/Condi Duration isn’t listed in the infix_upgrade’s attributes, but rather in a string.
- Some other stuff I’m forgetting.
Since these change the values of existing fields we’re returning, I personally consider them breaking changes and would like to (eventually) figure out a good way to make them to the v2 endpoint. It’s not really on the immediate list of things to do, though. If we do plan on breaking stuff in the future, we’ll probably post a topic about it to get feedback on the change before deploying it.
I think changes that add completely new fields to existing objects are non-breaking, e.g., if we add a “learned_from” field to v2/recipes that contains a list of item_ids (from which the recipe can be learned), I don’t currently think it’d be a big deal. I kind of feel the same way about flags — if there’s some flag we missed, I wouldn’t really consider it a breaking change to add it in — but I can definitely see the argument to the contrary there.
Let me know if that sounds crazy.
AggieTechGuy.4901:
We’ll try our best to keep everything working without changes on the application end. I don’t know if there’s going to be any HoT-related changes, but there definitely are some warts I’d like to see fixed, which include:
- The “Outfit” consumable’s type is currently listed as “Unknown”.
- Boon/Condi Duration isn’t listed in the infix_upgrade’s attributes, but rather in a string.
- Some other stuff I’m forgetting.
Since these change the values of existing fields we’re returning, I personally consider them breaking changes and would like to (eventually) figure out a good way to make them to the v2 endpoint. It’s not really on the immediate list of things to do, though. If we do plan on breaking stuff in the future, we’ll probably post a topic about it to get feedback on the change before deploying it.
I think changes that add completely new fields to existing objects are non-breaking, e.g., if we add a “learned_from” field to v2/recipes that contains a list of item_ids (from which the recipe can be learned), I don’t currently think it’d be a big deal. I kind of feel the same way about flags — if there’s some flag we missed, I wouldn’t really consider it a breaking change to add it in — but I can definitely see the argument to the contrary there.
Let me know if that sounds crazy.
Well then there’s not much to worry about. I try to keep static tweaks in my projects to a minimum, so those two breaking changes you listed wouldn’t actually break mine.
Personally, new fields or flags wouldn’t affect my projects. I can, however, see completely new data fields (not just flags) possibly breaking other’s projects that rely on RDBMS’ that have inflexible crawlers. NoSQL db’s should be fine, though.
Thanks for the response