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
[JsonProperty("dark")]
public BitImage dark { get; protected set; }
//assumed to always appear, so "light" is hard-coded
[JsonProperty("light")]
public BitImage light { get; protected set; }
}
public class BitImage
{
//assumed to always appear, so "animated" is hard-coded
[JsonProperty("animated")]
public Dictionary<string, string> animated_image { get; protected set; }
//assumed to always appear, so "static" is hard-coded
[JsonProperty("static")]
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?
Documentation
And a little something extra, there are fields that appear in the response that are not noted in the documentation:
