Server-side compatible with multiple different app versions

1. Achieve the goal

Release version n app, does not affect the normal use of the app before the N version, does not force users to upgrade the app version, compatible with the normal use of multiple versions of the app.

2, solve the idea

The server maintains APIs for different versions of the app (such as version Parameters V1, v2, v3 ...). ), dynamically invokes the corresponding API based on the URL and version information passed from the mobile phone side.

3. Common Scenarios

　　3.1 Common URL Request delivery version information in 4 ways

url+ version parameter: WWW.XXX.COM/API.XXX?VERSION=V1

www.xxx.com/sys/user/getUserByName?version=v1.0

www.xxx.com/sys/user/getUserByName?version=v2.0

Add version parameters in URL Post:header (similar to token usage)

URL path: www.xxx.com/v1.api.xxx.

Www.xxx.com/v1.0/sys/user/getUserByName

Www.xxx.com/v2.0/sys/user/getUserByName

Level two domain name: www.v1.xxx.com/api.xxx

Www.v1.0.xxx.com/sys/user/getUserByName

Www.v2.0xxx.com/sys/user/getUserByName

　　3.2 Server app code version management

Each app version corresponds to a project that deploys different versions of the app independently when publishing. You can use the SVN branching feature to manage different versions of project.

Reduces coupling, eliminates dependencies between versions, and is easy to maintain. Version-independent deployment, reducing the load pressure on a single node. However, there is a lot of duplicate code.

The same project is compatible with different app versions of the API. Different APIs are called depending on the requested version information (common routes, request forwarding methods).

Reduce duplication of repetitive code, but improper maintenance, easy to cause code bloat, increase dependencies between versions, bugs, reduce the maintainability of the code, do not support each version of the independent deployment.

4 recommendations

　　level two domain + one project for each app version. Demand is changing, and the app version is changing, the same API will be modified by many people, the original streamlined API over time becomes bloated, the API over-reliance, modify some of the code, resulting in other unknown errors, the code becomes difficult to maintain. It is therefore very useful to isolate each version of the app code.

　　

4.1APP how to invoke the server's API dynamically

The server version API is invoked each time the app launches, obtaining URL and version information. The client obtains the corresponding URL based on the default version number of the system. For example, if the pass version is v2.0, return www.v2.0.xxx.com

[    {        "name": "APP V1.0 Version",         "version": "v1.0",         "url": "Www.v1.0.xxx.com"    },     {        "name": " APP V1.0 Version ",         " version ":" v2.0 ",         " url ":" Www.v2.0.xxx.com "    }]

5. Number of app versions

Too many versions of the app are maintained, increasing maintenance costs. For some outdated versions of apps, older versions with less usage, incompatible databases, major feature upgrades, and so on, it is recommended to force users to upgrade.

Server-side compatible with multiple different app versions