Dealing with JSON differences because of previous versions

Question

How best to deal with the following problem:

I have an iPhone and Android mobile app that sends and receives data to a Webservice using JSON. My application needs to work offline, with users being able to run for weeks without internet, and when they make connection, the server receives the data and synchronizes.

However, if there is a change in Webservice in the meantime, the expected JSON may change (customer’s requirement). My solution was to make a layer of processing in Webservice that receives the JSON version of the App and converts the data to the format it expects. The problem is that each version that there is such a change requires the treatment layer to be updated for each of the previous versions.

I would like to know whether there is a better method for dealing with this case or whether I am already using the best method.

Grateful.

EDIT:

Being more specific in the treatment layer, I’m treating it as follows:

1. AJAX receives JSON from the App via POST, makes a simple validation and passes it for the Appdecodergeral class;
2. Appdecodergeral checks the version and instance the class responsible for the respective version of the app (eg Appdecoderandroid70);
3. Class Appdecoderandroid70 instance models according to their rules;
4. Models are handled by Controllers and Daos, etc;

My problem is in step 3, because I thought about using interfaces, however, an earlier version may not instantiate models that in newer versions are mandatory (for example when a new functionality is implemented).

For now I am continuing to treat case by case, updating each Appdecoder to deal with new features, but I see that so these classes will grow indefinitely.

Is there any better way to handle this case?

Answer 1

Do you already work with versioning right? Then you already have the solution in hand.

What I recommend is to indicate and use a pattern when making changes to the API, you can use Semantic Versioning as a basis.

Given a MAJOR.MINOR.PATCH version number, increment the:

major version (MAJOR): when making incompatible changes to the API, Minor version(MINOR): when add keeping features compatibility, and Fix version(PATCH): when to fix faults maintaining compatibility. Additional labels for pre-release(pre-release) and build(build) metadata are available as extension to MAJOR.MINOR.PATCH format.

_

Sources: http://semver.org/lang/pt-BR/

This way you can work better and standardize in case of incompatibility, forcing the user to update the application when online. It is important that the user is notified at the time of a new version and in case of incompatibility explain the reason for the update.

Your solution works, but in my view it is not efficient, it requires maintenance on both sides anyway. And the more you grow the more treatments you should do.

I hope I’ve been clear about inefficiency.