Bits response strucure questions

When implementing the new bits endpoint, I was looking at the structure of the response object received from the API and I’m curious the “best” way to deserialize the response. Right now, I am assuming that there will always be a light and a dark variant of the bit image and that there is always a static and a static and an animated of each bit image:

public class BitImages
    //assumed to always appear, so "dark" is hard-coded
    public BitImage dark { get; protected set; }

    //assumed to always appear, so "light" is hard-coded
    public BitImage light { get; protected set; }

public class BitImage
    //assumed to always appear, so "animated" is hard-coded
    public Dictionary<string, string> animated_image { get; protected set; }

    //assumed to always appear, so "static" is hard-coded
    public Dictionary<string, string> static_image { get; protected set; }

I did not feel right assuming that there will always be scales of x1, x1.5, x2, x3, and x4 so I left those to be deserialzed into generic Dictionaries.

Basically what I’m getting at, how rigid is the structure of the bits response? Is it required by Twitch that every bit image have a dark/light variant and a static/animated variant so that those will always appear in the response and can be hard-coded as such, or are these just “guidelines” and will only appear when available?. The same can be said for the scales, where right now I have them deserialized in to dictionaries or is it safe to assume there will always be 5 different scales of each image and can be hard coded as such?

And a little something extra, there are fields that appear in the response that are not noted in the documentation:

You seem to be using JSON.NET, so you can define all the possible data points in your class structure. Those that don’t exist in the deserialized json will be left as default(type) or whatever you’ve defined as default for the property. You’ll just have to do null-checks before using the data.

True, I could do that. However, this is for a library I’m developing so I don’t want to expose the user to any more properties than is necessary to avoid confusion.

The response format is staying the same for now. We don’t anticipate any changed to it.

Just to clarify, the top-level fields will tell you what will be populated. For example, if actions[0].states contains animated and actions[0].backgrounds contains dark, you will know that actions[0].tiers[0].images.dark.animated exists. Does that make sense?

Yeah, it makes sense. That’s what I was assuming but I wasn’t 100% sure if that what was actually happening.

I had no idea until I asked the engineers today when I saw this question. Haha. :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.