There may be valid reasons to deserialize in a stricter way. Consider this scenario: https://issues.redhat.com/browse/HAWKULAR-451?focusedCommentId=13089736&pag

There may be valid reasons to deserialize in a stricter way. Consider this scenario: https://issues.redhat.com/browse/HAWKULAR-451?focusedCommentId=13089736&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13089736 https://issues.redhat.com/browse/HAWKULAR-451?focusedComment... > For example, suppose we have JSON that represents a set of metric data (this isn't our real JSON, this is just a thought experiment) that should look like this, with "tags" being optional attribute: { "id": "1", "timestamp":"12:30pm", "value":"999", "tags": [ "myapp" ] } > Suppose a python client sends tags but calls the attribute "tag" rather than "tags" (its missing the "s"). Its an optional attribute, so the server won't consider it an error if the "tags" attribute is missing. But it also won't fail due to this unknown attribute called "tag" - it will just silently ignore it now. The Python developer is wondering why his tags aren't being stored - he is getting no errors but they are just silently being ignored. He would need to figure out he is sending in the wrong attribute name, with no error messages to help him out. > That's the use-case I'm asking about - the "silent error" that will occur due to malformed JSON messages.