Martin Fowler said to avoid automatic deserialization in an API:
I prefer to avoid automatic deserialization altogether. Automatic deserialization usually falls into the WSDL pitfall of coupling consumers and producers by duplicating a static class structure in both.
What this means?
Is it to receive all information as JSON in each Rest Service without any "converter" in the middle?
By "converter" I mean some type adapter, like in GsonBuilder.
By automatic deserialization he means that there's a predefined hard structure for the JSON object which is used to retrieve the object itself.
This is however appropriate for most use cases.
Examples of predefined structure are Java Class or XML XSD.
Automatic deserialization usually falls into the WSDL pitfall of coupling consumers and producers by duplicating a static class structure in both.
What he means here is that using classes for deserialization is same as using WSDL to serialize or deserialize objects.
On the contrary to the hard structure of classes and XSD documents, JSON is much more relaxed as it's based on Javascript which allows modification to the object definition at any point of it's life cycle.
So the alternative would be to use a HashMap and ArrayList in Java combination (or parsing String itself) to deserialize the object, as then even if the server produces something different (like new fields) no change would be needed at the client side. And new clients can take advantage of the new fields.
In a hard structure since both the producer and consumer are strongly coupled because of the shared structure of the model classes, any change in the producer has to be reflected in the consumer.
In some SOA projects where I worked, we used to add some extra fields in all the request/response objects for future use so that there was no need to change the clients running in the production to accommodate the needs of a new client. These fields had some random name like customParam1 to customParam5, where the meaning of these fields was released with the documentation. These names were not intuitive all because we were coupling the producer and consumer on the shared structure or models.