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
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.
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.
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.