vthornheart-bng
commented
5 years ago I see where you're coming from: if it helps, we do have some of this data available currently. If you look at any given response object, such as:
You'll see "Depends on Component __". That is, currently, the most clear way to tell which component you need to pass in order to get that data.
I can picture adding the opposite potentially - putting links to the given properties that the component will populate while looking at that Enumeration if that would be helpful, but it felt to me like it'd be more helpful for someone to see the components they should care about while looking at the actual response objects themselves rather than the enumeration. Does anyone else have an opinion on this matter? Has the "Depends on Component ___" documentation been useful, or would you rather have seen it reversed and on the enumeration itself - or both?
As far as naming it or adding new components to split them out, I don't plan to do so for a few reasons. Backwards compatibility is one, but the other has to do with scope reliability. I tried to name components a bit more generically in cases where I wasn't certain that components would remain specifically character, profile, or other-yet-to-be-determined scoped, or where it seemed unreasonable to return only one or the other when the concept was requested.
Kiosks was in the former case - and now that kiosks as a concept are deprecated, I'm not planning on changing that one. The others - presentation nodes, collectibles, and records - are concepts that I didn't picture originally would make much sense to request just the profile or the character version of that data. Where profile inventory gets you useful data that you can consistently rely on in that location on its own like vault items, the separation of presentation nodes/collectibles/records into profile and character components are coincidental and reliant on state that could be subject to change (and thus, a shifting of where any individual record or concept is located) in the future, without anyone informing me - and thus you - ahead of time).
There are a few components that I actually would have made more generic if I had it to do over again, such as Profile/Character Progressions that I no longer trust to be as stable in their data as it once was (indeed, for a long time there wasn't even a Profile Progressions component at all).
That's why some components are more split out than others, and in the case of the ones that are currently not split out I don't plan on doing so for those same reasons.
But I'd be interested in hearing other input - while I don't plan on changing the names of these components and breaking backcompat at least in this version of the API, I'd like to know if people feel like it'd be useful to have a "reverse lookup" of properties that are populated by a component while looking at the component in the documentation, or if you feel like the "Depends on Component __" documentation on the response objects are sufficient! Or if you have an alternative suggestion, let me know!
nine13tech
In the Profile components documentation, I'd like to see the documentation change to reflect the results from the API. For instance: Kiosks in the docs is really
characterKiosksin the API. This can be confusing to some people (like myself) when trying to make sense of all the data.https://bungie-net.github.io/multi/schema_Destiny-DestinyComponentType.html#schema_Destiny-DestinyComponentType