Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what are the ways of API version control". In daily operation, I believe many people have doubts about what are the ways of API version control. Xiaobian consulted all kinds of materials and sorted out simple and easy operation methods. I hope to help you answer the doubts about "what are the ways of API version control"! Next, please follow the small series to learn together!

By subdomain name (or subdirectory)

The first method is to directly use two modules (or applications) to implement, which is usually chosen for API versions with large architectural changes (especially when different versions basically cannot be shared, change the framework or even adopt different language implementations).

The structure of the directory is as follows:

api├─application │ ├─v1 │ │ ├─controller │ │ ├─model │ │ ├─config│ │ └─ ... │ ├─v2│ │ ├─controller│ │ ├─model │ │ ├─config │ │ └─ ... │ ...

request method

GET https://api.tp5.com/v1/user/1GET https://api.tp5.com/v2/user/1

Of course, you can also access it through the subdomain binding module in the following way

GET https://v1.api.tp5.com/user/1GET https://v2.api.tp5.com/user/1 by requesting parameters

For the initial version planning is not done well, and new versions are added in the later iteration maintenance process, considering the cost of architecture transformation, the following methods may be considered:

GET https://api.tp5.com/user/1GET https://api.tp5.com/user/1? version=v2

Due to the lack of a good path and library catalog specification, if you update the version frequently, it is recommended to upgrade the version architecture design to the latter two ways.

by routing

Most interfaces may have been designed with version control in mind, so you usually choose to add a version identifier parameter to the URL address, which is easy to debug.

For API applications, it is recommended to adopt a single module design + multi-level controller, the directory structure is as follows:

api├─application │ ├─controller│ │ ├─v1│ │ ├─v2│ │ └─ ... │ ├─model│ ...

Routing rules are defined as follows:

Route::get(':version/user/:id',':version.User/read');GET https://api.tp5.com/v1/user/1GET https://api.tp5.com/v2/user/1

Because of the use of multilevel controllers, attention needs to be paid to the namespace of the controller.

Controller files can be quickly created from the command line:

php think make:controller v1/User via header info

The latest specifications tend to define versions through header information. The advantage is that there is no need to change the URL address when iteratively updating from historical versions. There are two main types of header information.

The first is to use custom request headers such as api-version to control versions (you can also use other header information to control others)

GET https://api.tp5.com/user/1api-version:v2

The header information, the definition of the routing rule can be adjusted slightly:

use think\facade\Request;use think\facade\Route;$version = Request::header('api-version') ? : 'v1';Route::get('user/:id', $version . '.User/read');

There are also a lot of Accept header information to deal with (the advantage is that you can set the interface output format), the usual specification is

GET https://api.tp5.com/user/1Accept: application/vnd.tp5.v2+json Summary

For API interface development, try to plan for version control in advance to ensure that your application is compatible with new and old versions of access.

My summary:

The version number is passed through the api-version parameter in the header, and then routed to control access to specific controllers and methods

Here are the routes I configured myself:

Note that when configuring routing,". "Split indicates directory name

Indicates that api/version directory/arbitrary controller name/arbitrary method name will be accessed when api/arbitrary controller name/arbitrary method name is requested

The specific routing rules still depend on the official documentation

At this point, the study of "what are the ways of API version control" is over, hoping to solve everyone's doubts. Theory and practice can better match to help everyone learn, go and try it! If you want to continue learning more relevant knowledge, please continue to pay attention to the website, Xiaobian will continue to strive to bring more practical articles for everyone!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.