Using Adapter pattern to solve REST API Versioning issues

As mobile developers, we would deal with the API calls to Backend to get the information and save/render it on the UI screen.

As we heavily depend upon the response and its contract, a change in the response would eventually requires us to do a lot of changes in the application and the UI as well.

The API services can be internal or external. For example, if you are using an Internal service to render the user profile. After a certain point of time, the BE team might come with a new v2 service to support multiple addresses which was initially just an address or any other parameter changes or a change in the. hierarchy of elements.

This problem is more evident if you are consuming the external APIs. For example, if we are using google maps, google may come up with a new response model for the new SDK version to support or optimized for their needs.

Inherently, the problem is the same, you would need to change your subsystems whenever there is a change in the response.

How can we be able to build a system in which we would not require to change a lot of things especially on the UI Part and requires minimal changes in business logic?

That is where an Adapter pattern comes into the effect.

Let us assume that when we started off the development, the Profile V1 services used to return a single address, email, name, and mobile number. So we created our Model and ViewModel like the following.

After a certain point of time, the BE had come up with the V2 and start sending an array of addresses, office mobile numbers as well. So the V2 service now includes a different model.

We can not simply change the existing model as we are supporting both services for the user (AB testing or a Pilot feature) and he can opt-in whichever he is interested in. ( This may not be a great case for profile service, but taking this as an example. Let’s consider personalisation services, etc)

To solve the problem, I changed my view model and also introduced the Adapter model. This will make sure that the UI layer is not tightly bound with the models and less dependent on the contract/response changes.

This solution is not only limited to REST API responses but we can apply this anywhere to bridge the gaps in the model from the services or repositories to UI Layer.

Thank you for reading the article. Please provide your valuable feedback/comments for improving the article.