There's an issue with empty values that most recently came up in #2393 and #2303

While we've had this discussion before, I don't know if we even came to much of a decision. If a value for a property does not exist, should we either have the field as null or should it not exist, or should we can it to the type of the property. The best example of this is post_date_gmt which is not set on draft posts. Right now we return null for this field in the API response.

If we want to do this, we are effectively saying every field is either it's defined type, or null, and clients should act accordingly. Given we quite strongly avoided removing fields from the response when they won't have a value, then I think this is broadly the decision.

This leads on to: what happens when you try set a field value to null. This should surely be supported - as the API response has essentially legitimized the "valid" null value. Once suggestion in #2303 is to ignore any null values from an update, however that essentially makes null mean "this value doesn't exist now, but once we have a value, there will always be a value", which I think could work.

The main problem I have will stripping null values on update requests doesn't reflect the returned object, though on second thought that already happens in plenty of instances anyway.