Enhancement: QoL addition to API responses and Manifest data

[vpzed]

Something that would make the API responses and Manifest data (the data in the "json" column in the manifest tables) much more user friendly would be to add two fields (as shown below) to data objects that contain a "someThingLikeHash" entry (ex. plugItemHash). This would not apply to the primary "hash" entry.

The proposed enhancement is to add something like this:

existing:  "plugItemHash": 1294026524
new:       "plugItemRefName": "Adaptive Frame"
new:       "plugItemRefTable": "DestinyInventoryItemDefinition"

If the someThingLikeHash "lookup" did not have a displayProperties.name value then the someThingLikeRefName field would have a value of "" (empty string).

In the case of an array of hashes the respective someThingName field could be an array of name strings where the index of the name strings matched the index of the respective hashes. The someThingTable entry would remain the same (at least I haven't found an example yet where an array of hashes included entries that crossed multiple tables).

existing:  "modifierHashes": [3974591367, 1183352841]
new:       "modifierNames": ["Classified", "Classified"]
new:       "modifierTable: "DestinyActivityModifierDefinition"

The way the extra fields are named in the example isn't meant to be the only way of doing it, it's the concept of providing the most basic of de-references - the displayProperties.name value - in the data, and providing a pointer to where the rest of the data resides if one needs more than the name.

I think this concept would provide a big Quality of Life improvement for API users.

[floatingatoll]

This reminded me of #62 which refers to #10, which may provide a useful crumbtrail.

[vpzed]

Excellent. The more context the better. This addresses some of the issues in both of those threads:

• Providing the name value which is commonly the only reason people are doing the hash lookup.
• NOT including the full definitions for the referenced data.
• But providing a clear reference to where to find the referenced data.

[vthornheart-bng]

I can definitely see why you'd want to have this data, but I don't think we're in a good position to provide these in our contracts for Destiny 2 at least. There's a few reasons, some being the way we manage the data on our side (and how we keep concerns like output caching manageable on our side), and some being redundancy of data when we provide it by other means - admittedly less convenient means, but more bandwidth-friendly ones.

On our side of the fence, we've been very careful to craft our Destiny contracts such that no localized data is included. This was an intentional decision that simplifies parts of our architecture and allows us to make the caching that handles our results locale agnostic. It also allows clients to deal with the Destiny API's live calls in a locale agnostic manner if they wish to make similar optimizations (particularly if/since they're already going to have to handle their own localized destiny manifest databases).

For the table relationships, we provide the related table information through metadata in our documentation and in the Swagger spec, which allows us to avoid having to send that data over the wire for every relationship whenever someone makes a request. This does unfortunately make the relationship less discoverable if someone is learning our API by - for example - watching transmissions across the wire. But part of why we wanted to build out the more robust documentation was so that we'd have a place that we could put this kind of information in an easy to access format. While the documentation and specs aren't quite as convenient as literally having them on the response, my hope is that these have served as a good compromise between having nothing (as we did in D1) and returning all of this metadata every time (which we don't want to do).

I appreciate the suggestion! I hope that this information is helpful in giving context for why I wouldn't be inclined to make this change, but I definitely appreciate it: and I totally understand where there are use cases where this would be convenient to have available. I just can't justify the tradeoff at this time.

I could see a world where, perhaps someday when we have time, we could look at approaches to altering our endpoint or even providing a new v2 endpoint that gives back some of the flexibility that we had in D1 when we were returning definitions: something where perhaps you could request specific subsets of the definition (such as the name, or even those table relationships, as you mentioned). I just don't picture us having the time to get around to designing or implementing that anytime soon. I think it's something that'll be best suited for us to keep in mind as an improvement for the next iteration of Destiny! (which reminds me, I need to think up a good way to organize issues that I'd like us to think about for a theoretical Destiny 3's API, but that I know we won't have time to get to in the Destiny 2 timeframe, like this one. For now I will just use a tag.)

[vpzed]

Thanks for the detailed response.

[bhollis]

FWIW my vote is for things to stay the way they are - referencing other tables by hash is great, and keeps the responses smaller (we're already struggling with how huge everything is!)