Dealing with JSON differences because of previous versions

Navigation
0

What is the best way to deal with the following problem:

I have a mobile iPhone and Android application that sends and receives data to a Webservice using JSON. My application needs to work offline, with users being able to stay weeks without internet, and when they can connect, the server receives the data and synchronizes.

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

I wonder if there is a better method to handle this case or if I'm already using the best method.

Thank you.

EDIT:

Being more specific in the treatment layer, I'm treating it like this:

  • AJAX receives the JSON from the App via POST, does a simple validation and passes it for the General AppDecoder class;
  • AppDecoderGeral checks the version and instantiates the class responsible for its app version (eg AppDecoderAndroid70);
  • AppDecoderAndroid70 class instantiates the models according to their rules;
  • Models are handled by Controllers and DAOs, etc;

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

    For now I'm following case by case, updating each AppDecoder to handle new features, but I see that these classes will grow indefinitely.

    Is there a better way to handle this case?

        
    asked by anonymous 13.10.2016 / 22:20

    1 answer

    0

    Have you ever worked with versioning right? So you already have the solution in hand.

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

      

    Given a version number MAJOR.MINOR.PATCH, increase to:

         

    MAJOR version: When you make incompatible changes in the API,   Minor version: when adding features while maintaining   Compatibility, and Patch (PATCH) Version: When Fixing Failures   maintaining compatibility. Additional labels for   pre-release and build metadata are   available as an extension to the MAJOR.MINOR.PATCH format.

         

    _

         

    Sources: link

    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 be 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 point of 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 was clear about inefficiency.

        
    13.10.2016 / 22:46
    Search in visual studio Problem with Datatables in Laravel 5.2