You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently have all fields returned by an API in kebab case (eg: first-name), which wants to convert to camel case for consistency with other systems (eg: firstName).
This is obviously a breaking change, so the right way to do it would be the API including both versions of the field (kebab + camel), giving sufficient time for folks to migrate from the deprecated key name, and then removing the deprecated fields.
As an improvement, to further decouple the API and consumer applications, it would be great to have this support added to JsonNaming or JsonAlias
Currently, we have @JsonNaming(PropertyNamingStrategies.KebabCaseStrategy.class) at the top of our class to have all fields being deserialized from kebab case. Maybe JsonNaming can take another param aliasStrategies = {AliasStrategy1.class, AliasStrategy2.class} to indicate alternate naming pattern as aliases only, i.e. both naming conventions should be permitted for deserialization (default, or aliased), while serialization would continue to use the primary convention.
An alternative would be to allow @JsonAlias to be applied at the class level, with a PropertyNamingStrategy as its value instead.
Or if its not a good idea fitting this into existing annotations, create a JsonNamingAlias which can be used like the following:
If there are fields in the json to be deserialized which point to the same key with different naming formats (eg: {"first-name": "codi1", "firstName": "codi2"}, then just follow what happens when JsonAlias are applied to a field with multiple aliases (I believe the precedence is actual property name (or JsonProperty if present) followed by first matched alias)
The text was updated successfully, but these errors were encountered:
If anyone has time & interest they are free to propose an implementation. This sounds like a rather complicated thing to implement so I don't really have time to look into it any further myself, but maybe someone else has.
Java: 11.0.10
Jackson: 2.12.2
We currently have all fields returned by an API in kebab case (eg:
first-name
), which wants to convert to camel case for consistency with other systems (eg:firstName
).This is obviously a breaking change, so the right way to do it would be the API including both versions of the field (kebab + camel), giving sufficient time for folks to migrate from the deprecated key name, and then removing the deprecated fields.
As an improvement, to further decouple the API and consumer applications, it would be great to have this support added to
JsonNaming
orJsonAlias
Currently, we have
@JsonNaming(PropertyNamingStrategies.KebabCaseStrategy.class)
at the top of our class to have all fields being deserialized from kebab case. MaybeJsonNaming
can take another paramaliasStrategies = {AliasStrategy1.class, AliasStrategy2.class}
to indicate alternate naming pattern as aliases only, i.e. both naming conventions should be permitted for deserialization (default, or aliased), while serialization would continue to use the primary convention.An alternative would be to allow
@JsonAlias
to be applied at the class level, with aPropertyNamingStrategy
as its value instead.Or if its not a good idea fitting this into existing annotations, create a
JsonNamingAlias
which can be used like the following:If there are fields in the json to be deserialized which point to the same key with different naming formats (eg:
{"first-name": "codi1", "firstName": "codi2"}
, then just follow what happens whenJsonAlias
are applied to a field with multiple aliases (I believe the precedence is actual property name (orJsonProperty
if present) followed by first matched alias)The text was updated successfully, but these errors were encountered: