Multi-version API management practices developed by PHP

PHP-developed API multi-version management practices

This article focuses on mobile Internet clients that need to be compatible with the old version. force upgrade to the latest version of the app is not discussed here.

In the bugtags.com project, our version complies with the following specifications.
1.0.1
Major features, minor updates, 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

In this version structure, all versions can be used. if the span is the maximum, 1.0 users and 5.0 users coexist.
Take the/api/user/info interface as an example. after so many iterations, the returned data structures of versions 1.0 and 3.0 may be completely different.
For such a system, it is very important to design a complete version architecture.

Difficulties

Mobile Internet is different from traditional web development. Compared with traditional web development, quick iteration and version upgrade have the following difficulties:

User acquisition is difficult, with a low retention rate

High client upgrade cost, some users refuse to upgrade

Large amounts of code are available on multiple versions of servers, resulting in high maintenance costs.

Purpose and requirements of the architecture

Simplified version management process and easy configuration management

Reduce the size of php code on the server

Try not to introduce new elements

Discuss the request form conventions in the group

Use a domain name, suchV1.api.bugtags.comInterface version

Put the version information in pathinfo of the url, as shown in figureApi.bugtags.com/v1/

Put the version information in the request parameters, as shown in figureApi.bugtags.com/user/1? _ Ver = 1.0.1

Put the version information in the http header, as shown in figureAPI_VER: 1.0.1

Using domain names for version numbers is a relatively unrecognized solution, mainly because domain names are often managed across departments, increasing communication costs.
The http header is one of my favorite methods to keep the url clean.
The url parameter carries the version number in a good way, but be careful not to be duplicate with the parameter name of the business logic.

Two common code management methods: git/svn tag management

Advantages: low branch switching costs at any time, especially when git manages code.
Disadvantage: if multiple versions need to be modified, the code merging workload is heavy.

There is only one branch, which can be determined based on version information in the code.

Advantage: The overall size of the code is small (only one piece of code is available)
Disadvantages: there will be a large number of branch statements where you need to determine the version

My summary

The final solution fully utilizes the php autoload loading mechanism and namespace.

Assume that base is the foundation of all services, the first version, and the longest life cycle version.

V10 version1. x. xProvides services to eliminate the version logic judgment on the business point to the maximum extent, but does not absolutely reject them.

V20/v30 developed based on v10

V40 is developed based on v30

Example

V10 provides three interfaces: a, B, and c.
V20 provides three interfaces: a1, B, and c. a1 is a modification.
V30 provides three interfaces: a, b1, and c. b1 is the modification of B.

Use the following three pieces of code to describe

Configuration version:

• Basic directory base stores most of the public code

• The version directories v10 and v20 are both version directories, which store different logics of this version and the basic version.

• The version difference is based on the file as the minimum granularity, as shown in the code above.

The user wants to access/api/user/info? Ver = 3.0.1 at this time, the class loading order is:

Failed to load Config. php under v30

Failed to load Config. php in v10

Config. php is successfully loaded in Base.

Execution logic

This limit can only be inherited from one layer because the complexity of the system is minimized. Code management in this way has been verified in several projects. The complexity of system code can be greatly reduced, especially when multiple versions are iterated and cannot be forcibly upgraded. Note the following:

When using this method for loading, after several versions have been accumulated, the general part should be gradually accumulated into the BASE version.

It is best to have the file deletion function in the publishing system. Otherwise, the higher version will still use the code after it is partially precipitated.

I am developing and operating bugtags.com, which is an SDK product that can greatly improve the test efficiency of app developers. welcome to use and forward recommendations.

Our team has been seeking the PHP backend for a long time. if you are interested, add the following public code to hook up: