PHP Development API Multi-version management practice

The situation encountered

In this article, for mobile Internet clients that need to be compatible with older versions, forcing an upgrade to the latest version of the app is not in the discussion list.

In the Bugtags.com project, our version follows the specifications below.
1.0.1
Big feature. Minor update. Bug fixes
Our version list is as follows:

1.0, 1.1, 1.2, 1.3, 1.4
2.0, 2.1, 2.2, 2.3
3.0, 3.1
...
5.0

Such a version of the structure, all versions can be used, the maximum span, 1.0 users with 5.0 users to coexist.
With the/api/user/info interface example, after so many iterations, the return data structure of version 1.0 and 3.0 may be completely different.
For such a system, how to design a complete version of the architecture is very important.

Understand the difficulties

The mobile internet is different from traditional web development. Its rapid iterations and version upgrades have the following difficulties compared to traditional web development:

1. User access difficulty, low retention rate
2. High client upgrade cost, partial user refused upgrade
3. Multiple versions server-side code volume, sharply high maintenance costs

Purpose and requirements of the architecture

1. Simplified version management process, easy configuration management
2. Reduce the size of PHP code on the server side
3. Try not to introduce new elements

The agreement of the form of discussion request in the group

1. Use domain names, such as v1.api.bugtags.com , to differentiate the version of an interface
2. Place the version information in the pathinfo of the URL, such as api.bugtags.com/v1/
3. Put the version information in the request parameters, such as api.bugtags.com/user/1?_ver=1.0.1
4. Place the version information in the HTTP header, such as api_ver:1.0.1

Version number with the domain name is a relatively non-recognized solution, the main reason is that domain name management often across departments, increased communication costs.
The HTTP header is my personal favorite way to keep the URL neat.
It is also good to carry the version number in the URL parameter, but be careful not to repeat the parameter names of the business logic.

Two common ways to manage Code GIT/SVN tag Management method

Advantage, switching branch costs at any time is low, especially when Git manages the code.
Disadvantage, the code merge workload is large if multiple versions need to be modified.

There is only one branch, which is judged by the version information in the code.

Advantages, the overall size of the code is small (only one code)
Disadvantage, there will be a large number of branch statements where the version needs to be judged

The solution I've summed up

The final solution takes full advantage of PHP's autoload loading mechanism and namespace.

1. Suppose base is the foundation of all business, the first version and the longest version of the life cycle.
2. V10 provides services to version 1.x.x , minimizing version logic on business points, but not absolute rejection.
3. V20/V30 based on V10 version development
4. V40 version based on V30 version development

Examples Show

V10 provides a,b,c three interfaces
V20 provides a1,b,c three interfaces, A1 is a modification
V30 provides a,b1,c three interfaces, B1 is a modification of B

Use the following three sections of code to specifically describe

<?php/** * view/api/base/config/config.php * *namespace View\Api\Config; class Config { function index() {Echo __method__;}}?>

<?php/** * view/api/v10/config/config.php * *namespace View\Api\Config; class Config { function index() {Echo __method__;}}?>

<?php/** * view/api/v20/config/config.php * *namespace View\Api\Config; class Config { function index() {Echo __method__;}}?>

Configuration version:

Access version	Code version
V10	Base
V11	Base
V20	V10
V30	V10

• Base directory base stores most common code
• The version directory v10/v20 is a version directory, which contains different logic for this version and the base version
• The version difference is the minimum granularity of the file, as can be seen in the above three sections of code.

User to access/api/user/info?ver=3.0.1 at this point, the load order of the classes is:

1. Attempt to load config.php failed under V30
2. Attempt to load config.php failed under V10
3. Attempt to load config.php successfully under Base
4. Execute related logic

This is because the limit can only inherit one layer because the complexity of the system is reduced as much as possible. This way of managing code has been verified in several projects. The complexity of the system code can be reduced to a great extent, especially in multiple versions of iterations, which cannot be forced to upgrade the system. It is also important to note that:

1. When handling loading in this way, after several releases of precipitation, the general part should be gradually precipitated into the base version
2. The release system is best with the delete file feature, otherwise it will be partially precipitated, the higher version of the code is still using the high version.

I am in the development and operation of Bugtags.com, this is a great upgrade app developer testing efficiency of the SDK products, welcome to use, forwarding recommendations.

?

PHP Development API Multi-version management practice