Should the object mapper be more forgiving?

[stil4m]

Deserialization fails when unrecognised fields are added to the API. Now we notice this directly in the nightly build. But when you use the Api in production it would be nice that the added fields are just ignored.

An approach would be to:

• make the default object mapper to be more forgiving
• make the object mapper that is being used in the integration tests as strict as it currently is.

Any ideas on this?

[tubbynl]

in my opinion the adding of new fields in the API should not result in breaking existing production deployments of the mollie-client so i prefer making the default object mapper more forgiving and having a nightly build running a strict object mapper would be nice to detect api changes early

but if the latter happens really often it might backfire on it's purpose

maybe @jcassee also has a view on this

[tubbynl]

Daamvm (from Mollie) in #23

You're right stil4m, the resource attribute is only added for payments which have an API customer. We wanted to make the endpoints more consistent by adding the resource attribute to each response. We didn't want to break existing implementations, so that's why wo only added it to payments with a customer.

I can imagine it's confusing the way it's right now. I'll report it internally, we can at least update the docs.

Further would I recommend ignoring unknown fields from our API. We might occasionally add new fields, for example to the payment details object for new payment types. Note that it will never be backwards incompatible when you ignore the unknown fields.

[stil4m]

Fixed with #29