I came across a subtle 'best practice' dilemma. But first, the context:
I work on several REST Springboot based microservices in which it was decided that every each of them will have API modules extracted. The idea behind that is:
Whenever you need to communicate 2 microservices with each other, just add API module dependency, and voila. You can serialize/deserialize with Plug&Play experience.
And this is great for keeping it simple and consistent in communication between any of these services.
However for the newly created microservice, within its API there is a class with a single string value like:
public class Fog {
private String value;
private Fog() {
}
public Fog(final String value) {
this.value = value;
}
public String getValue() {
return this.value;
}
}
The problem is that now this class will be serialized like
<{value=fa2a81f4-8412-41f9-8656-c94487f224ec}>
And not like:
"fa2a81f4-8412-41f9-8656-c94487f224ec"
And no, this class cannot be replaced just by a string in its parent object for several reasons.
And there are 3 solutions to this problem of which I am aware of, but none seems to be 100% satisfying to me:
- Leave like this, and create serializer/deserializer and register it in service which is importing that model -> Losing the Plug&Play experience.
- Create a MixIn and register it in object mapper - same story, no more Plug&Play experience.
- add @JsonValue annotation - Besides the fact that it is breaking my rule that "API model classes should be vanilla Java, I'm now forcing someone to include FasterXML Jackson library for serialization/deserialization.
Is there a 4th option that could possibly let me keep the plug&play experience and keep my API module abstract from the serialization/deserialization library?