philwebb
commented
5 years ago Every default has a trade off, but I feel like our current approach works well for most of our users. Specifically, I like the fact that the JSON I'm consuming can have additional fields added without my application breaking.
It's also very easy to change the defaults if they don't work for you by adding the following to your application.properties file:
spring.jackson.deserialization.fail-on-unknown-properties=true
harish-prakash
Should Boot disable by default
FAIL_ON_UNKNOWN_PROPERTIESin the ObjectMapper configuration?Jackson's stock configuration actually fails deserialization whenever it encounters an unknown property. The only argument against this is Postel's law which has been challenged in recent days
Though RFC 3117 and PoPETS article do not talk about HTTP (Postel's law itself mainly focused on TCP) they are very good examples why unmanaged rejection is not always a good idea.
Furthermore FasterXML's Jackson team had a very good reason why not to blindly follow the law. (reference).
My question is, why would spring decide to deviate from a structured default? I understand the general concern for backward and forward compatibility, would it not be more efficient if implementations explicitly accepted unknown properties and logged them instead of Spring deciding to silently drop them?
Some may find this question intentionally begins the same way its counter-request did a few years ago. Issue #1237