tp5.1使用总结(2):API版本控制4种思路

引言

        我们假设API接口的域名名为api.tp5.com,并且以两个版本v1和v2为例(注意,版本号仅为主版本,小版本应该是直接升级,不应该存在共存情况,所以v1.1或者v2.0这种版本号不应该设计在URL里面),来说明下API版本的不同控制方式,以及应该如何进行开发的规划。

        API版本控制在tp5中四种思路:

            1:通过子域名或子目录

            2:通过请求参数

            3:通过路由

            4:通过头部信息


一:通过子域名或子目录

        1:代码部分:直接使用两个模块(或者应用)来实现

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

        2:请求方式

#子目录
GET https://api.tp5.com/v1/user/1
GET https://api.tp5.com/v2/user/1
#子域名绑定模块实现下面的方式访问
GET https://v1.api.tp5.com/user/1
GET https://v2.api.tp5.com/user/1

            3:总结

            对于架构改变比较大的API版本(尤其是不同版本之间基本没法共用、更改框架甚至采用不同的语言实现)通常会这样选择。


二:通过请求参数

        1:请求方式

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

        2:总结

            对于刚开始没有做好版本规划,后期迭代维护过程中增加了新的版本,考虑到架构的改造成本,可以考虑这种。

            缺点是:缺乏很好的路径和类库目录规范。

三:通过路由

    1:代码部分:单模块设计+多级控制器

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

    2:请求方式

#路由定义
Route::get(':version/user/:id',':version.User/read');

#请求url
GET https://api.tp5.com/v1/user/1
GET https://api.tp5.com/v2/user/1

    3:总结

    可能大多数接口在设计的时候已经考虑到了版本控制的问题,那么通常会选择在URL地址中增加版本标识参数,这种方式便于调试。

四:通过头部信息

        最新的规范趋向于通过头信息来定义版本,优势在于从历史版本迭代更新的时候不需要改变URL地址,改变请求头信息即可,主要分为两种

    1:自定义请求头例如api-version控制版本(同理你还可以用其它头信息控制其它)

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


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

    2:Accept头信息来处理(好处是可以设置接口输出格式),通常的规范是

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


阿群博客
请先登录后发表评论
  • 最新评论
  • 总共0条评论