Suggestion - id and uri properties on objects required by convention.

[DDtMM]

It would be great if all fields that weren't optional were marked as required, but I don't know a reliable way you make that determination from the documentation.

It would be nice if at least the id and uri fields on response objects were required. I think it is more justifiable than other fields to expect this since they are identifiers on the objects. From observation, the id and uri properties are never null when being returned from a request.

The benefit here is that clients that are generated from the specification won't make those two properties nullable. It's minor nuisance having null checks sprinkled throughout code that relies upon generated classes.

Thank you for your consideration.

(maybe all fields could be required unless the phrase "null" is in the description - that seems pretty cheesy though, and can be problematic given some array members can come back null.)

[sonallux]

Thanks for your suggestions. I had already considered this as a possible feature to add. But as Spotify is now sourcing its Web API reference documentation from an Open API definition, this whole project is now kind of obsolete. Please also see #114

The Open API definition from Spotify is already marking fields as required in its model definition. Unfortunately currently not for Artists and Playlists, but this will hopefully follow soon.