New timestamps in DestinyProfileResponse for clients to handle stale data

[jshaffstall-bng]

Ahead of the update to the Bungie.net API on December 6th, 2022 for the Season 19 release, we wanted to give everyone a heads up about one specific change.

We're adding these two new values to the DestinyProfileResponse object from the Destiny 2 GetProfile API.

responseMintedTimestamp (ISO 8601 date-time string) "Records the timestamp of when most components were last generated from the world server source. Unless the component type is specified in the documentation for secondaryComponentsMintedTimestamp, this value is sufficient to do data freshness"

secondaryComponentsMintedTimestamp (ISO 8601 date-time string) "Some secondary components are not tracked in the primary response timestamp and have their timestamp tracked here. If your component is any of the following, this field is where you will find your timestamp value: PresentationNodes, Records, Collectibles, Metrics, StringVariables, Craftables, Transitory All other component types may use the primary timestamp property."

Here's a preview of the OpenAPI spec JSON for these properties:

"Destiny.Responses.DestinyProfileResponse": {
  "type": "object",
  "properties": {
    "responseMintedTimestamp": {
      "type": "string",
      "description": "Records the timestamp of when most components were last generated from the world server source. Unless the component type is specified in the documentation for secondaryComponentsMintedTimestamp, this value is sufficient to do data freshness.",
      "format": "date-time"
    },
    "secondaryComponentsMintedTimestamp": {
      "type": "string",
      "description": "Some secondary components are not tracked in the primary response timestamp and have their timestamp tracked here. If your component is any of the following, this field is where you will find your timestamp value:\r\n PresentationNodes, Records, Collectibles, Metrics, StringVariables, Craftables, Transitory\r\n All other component types may use the primary timestamp property.",
      "format": "date-time"
    },

We understand that the manual mapping of these timestamps is not ideal, but these values should be sufficient for implemented client-side cached-response-handling behavior.

[justrealmilk]

So if I do use secondary components, I would want to compare both time stamps each time?

[serkanbal]

Will the DestinyProfileResponse caching start with the addition of these two values on December 6th, 2022? Or is it just to prepare for profile response caching at a later date.

[jshaffstall-bng]

So if I do use secondary components, I would want to compare both time stamps each time?

I think the secondary timestamp will only be populated if you request any of the 'secondary' components. So you could do per-component-group timestamp comparisons.

[jshaffstall-bng]

Will the DestinyProfileResponse caching start with the addition of these two values on December 6th, 2022? Or is it just to prepare for profile response caching at a later date.

We don't want to introduce aggressive response caching behavior in the near term, unless we have to for service stability.

For any changes to caching in the S19 launch window, we'll try to communicate that out as it's happening.