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.)
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.)