-
Notifications
You must be signed in to change notification settings - Fork 23
Description
Intro
For Joda Money module, we have the possibility to select the amount representation on module level. Amount representation varies from API to API. In projects that involve integration with many APIs it would be beneficial to allow such selection on field-level. This ticket collects possible approaches.
Appoaches
To achieve field-level selection we could:
- Leverage
@JsonFormat
'sshape
(see comment #1 and comment #2):
@JsonFormat(shape = NUMBER_INT)
Money grandTotal;
Characteristics:
- This has the benefit of leveraging existing annotation related to formatting without the need to introduce a new one.
- We will still have to document the behavior of
@JsonFormat
on Money (de)serializers as it won't be obvious whatshape
s are supported and what effect they have. - It might be a bit confusing to some, as the annotation doesn't influence the field itself but rather a particular nested property.
- It doesn't help with potential further extensions. As an example, the naming of the properties varies from API to API - I've integrated systems with services using
currencyCode
instead ofcurrency
andvalue
instead ofamount
as the names of the individual properties carrying the monetary amount. If we wanted to allow customization of the names in the future, most likely we wouldn't do that via@JsonFormat
annotation but rather a dedicated one.
- Introduce dedicated annotation (here:
@JsonMoney
) allowing selection of amount representation (see comment):
@JsonMoney(amountRepresentation = MINOR_CURRENCY_UNIT)
Money grandTotal;
Characteristics:
- We have to introduce a new annotation, mention it in README and document in JavaDocs.
- We are open for further extension (argument with custom property names above).
- Do a mix of the two - extend
@JsonFormat
to allow passing (de)serializer-specific annotations (here: via newwith
attribute):
@JsonFormat(with = @JsonMoney(amountRepresentation = MINOR_CURRENCY_UNIT))
Money grandTotal;
Characteristics:
- We configure the format the way users might be used to do it.
- We are open for further extension (argument with custom property names above).
- We have to introduce a new annotation, mention it in README and document in JavaDocs.
- We have to modify
@JsonFormat
just for the sake of passing custom annotations.
Implementation
Regardless of the approach, most likely Contextual(De)Serializer
would be used to build the (de)serializer.
Discussion
Do you see some more characteristics of these approaches?
Do you see a clear winner? (I'm slightly leaning towards approach 2)
Of course we don't have to pull the trigger now - might as well keep this open until we have more insights or convictions. Just wanted to write down my thoughts.