Jackson : Make the most of POJO versus Immutable Objects

There is a simple dilemma that comes into my thoughts :
-> I have an object, right… class A { String b;int c}
-> It must be filled automatically thanks to unmarshalling from a json string {"b":"val1","c":2}
-> I want it to be immutable because I don’t want to alter my input, or to trust some insecure hashcode/equals methods.

Therefore : I must have a deserializable class, with final fields, a comprehensive constructor, and a builder pattern.

That sounds awkward with jackson. But is it possible ? Yes, it is, and I’ll prove it.
https://gist.github.com/libetl/853029faf7999c98159f36d1c229c961#file-a-java

Neat, but let’s complicate this attempt a bit. Suppose we have a polymorphic object to be deserialized. It is a paradigmatic issue between Java and Json : Java is typed, Json does not care.
let’s declare this in pseudo DSL : class TripSegment { TransportMode mode; SegmentDetails detailsOfTheSegment }
with enum TransportMode { FLIGHT, TRAIN, BOAT, CAR_SHARING, LOCAL_TRANSIT }
and with several details classes like this one : class LocalTransitDetails implements SegmentDetails {String lineCode;DateTime timeOfDeparture;DateTime timeOfArrival;String departureStationName;String arrivalStationName;}

We want neither to create a TripSegmentBean as a POJO, nor to have a non jackson deserializer… So how to ?
Here is how I could successfully answer to that problem :
https://gist.github.com/libetl/853029faf7999c98159f36d1c229c961#file-tripsegment-java

Now, I can handle my unmarshalled value object as if I built it manually. Now forget about dozer or BeanUtils. Let’s concentrate on the workflow.

Smart HATEOAS APIs

Hello.

It is always useful to navigate in an API as easily as in an HTML file.
Who have ever dreamt of a clever software code able to browse all the relevant data just by browsing an API document ?

Here is how :
– build an API result with links. Your links must be accessed like you would do in a css file (<link rel= »stylesheet » href= »path/to/the/file>)
– trust your MVC framework to remind you which links are associated to your current resource (find in the Request Mapping the relevant links)
– give the user a root resource where you can find a « menu » of your APIs. A simple test can convince you that your APIs links work : use Postman, and try to reach a single resource from the root resource.

You can find an example about how it works with Spring MVC 4.2 . Give it a try to my simple web app https://github.com/libetl/RESTAndSpringBankAccountWebApp. Fork this repo, scaffold it to build your own APIs, make yourself at home.