App version upgrade background interface compatible with the old version

Artificial intelligence, zero-based entry! http://www.captainbed.net/inner 

When a company develops an APP, there are often version upgrades, so there is a problem of how the new version is compatible with the old version.

New versions of iOS and Android are constantly being developed. Many server-side developments are based on the logic of the previous interface. After the new APP version is released, how can the old APP version be compatible with the interface?

Some people say: Every time the app is released, the user is forced to update to the latest version. Now some companies do this, of course it is not recommended, such a user experience is too bad.

Even if the update is mandatory, the new APP interface and the old interface must be able to be used at the same time during Apple's review.

Let's talk about how to do it below. We use the last one. If you have different opinions, you can leave a message for discussion.

1. The client is compatible, the interface does not need to be compatible

1. APP mandatory update (not recommended)

Interface URL: api.xxx.com/v1.0/xxxx.java

Add the version number to the URL of the interface, as above: v1.0.

Each APP is forced to update, and the grayscale server deploys the interface version under review (for example: v1.1). After the review is passed, the old version of the APP settings will be forced to update, so that the old interface is no longer needed.

Then re-deploy the online server with the latest server-side code, and then remove the gray server.

In this way, all APP interfaces access the official online server.

2. Hot update

You can use hot update for urgent and important small requirements. For big requirements, it is recommended to use native code, because you have to modify the JS or Lua code after using hot update to modify the native code.

Many online games use hot updates. Because the APPs of online games are too large to add a small level, users are required to re-download them. The game updates are more frequent than enterprise-level apps. Hot updates can continuously add new levels and scenes.

3、React Native 和Weex

Weex is better than React Native, I suggest you try it. Personally, I suggest not to use them on a large scale, after all, they are only third-party things, and some things are not perfect.

Two, the server is version compatible

Whether all interface versions are unified:

[1] All interfaces have a unified version number: In this way, if you want to send a new version of the APP, you will need to modify the version number uniformly. It is easy to modify, but if you want to modify the version number of one of the interfaces, it will not work.

[2] The version number of each interface can be different: this is more flexible, and it is recommended to do so.

1. Add if judgments to each interface logic (not recommended, this will make the code too bloated, in fact, almost no one does it)

Interface URL: api.xxx.com/api?version=v1&..

if (version == ‘1.5.0’) {

do_something

} else if (version ==‘1.4.0') {

do_something

}

Advantages: simple to implement

Disadvantages: It is easy to cause code confusion, which is not conducive to maintenance.

2. Different folders

Equivalent to each interface version is an independent project. Put it in a separate folder on the server.

E.g:

Interface URL: api.xxx.com/v1.0/xxxx.php

Folder location: Controller/V1.0/

-----------------/xxxx.php

Folder location: Controller/V2.1/

-----------------/xxxx.php

Advantages: The version logic is maintained separately. Look at the url to know which version. Delete the redundant version without modifying the code.

Disadvantage: Duplicate files of different versions of the same interface. And if there is a problem with the previous version of the interface, it has been left until now, and several sets of the same code need to be changed.

3. Different versions use different methods:

Interface URL: api.xxx.com/v1.0/xxxx.php

class XXXX{

public functionv1_0_0() { }

public functionv2_0_0() { }

}

To sum up, the 2 and 3 methods are the easiest way to achieve back-end compatibility, which is equivalent to adding a new interface. PS: Our company is currently doing this.

 

Guess you like

Origin blog.csdn.net/qq_35860138/article/details/101532052