[发明专利]API网关中的API版本控制方法、装置及存储介质

说明书

本公开提供了一种API网关中的API版本控制方法、装置及存储介质，用于API版本控制中业务侵入、代码冗余的技术问题。本公开在API网关的组件架构基础上，通过新增版本控制组件，实现API版本与服务下的上游服务组件的绑定，能够根据客户端请中所携带的API版本参数将请求转发给指定API版本的上游服务组件进行处理，在服务端实现了不同版本的服务与对应的API版本的绑定，服务端不需要将不同版本的API混合在一个服务当中提供服务，从而减少业务的侵入、代码的冗余，实现了API版本的统一管理和控制。

技术领域

本公开涉及互联网技术领域，尤其涉及一种API网关中的API版本控制方法、装置及存储介质。

背景技术

应用程序编程接口API是API提供者与API使用者之间建立的纽带。正常情况下，API版本不会轻易变动，一旦API提供者将API对外公开发布，就必须保持它是可用的并且不会影响到已有的使用者。如果是遇到多个项目，则需要对API进行版本控制，以防止影响到现有的API使用者。

API的版本控制策略一般有以下3种模式：

(1)The Knot无版本模式，即API永远只有一个版本，所有的API使用者都必须使用最新的API，任何API的修改都会影响到API的已有使用者。

(2)Point-to-Point点对点模式，即API自带版本号，API使用者根据自己的需求选择使用相应API版本。

(3)Compatible Versioning兼容版本控制模式，和The Knot一样，API只有一个版本，但最新版本需要兼容以前的所有API版本。

RESTful是一种网络应用程序的设计风格和开发方式，基于HTTP，可以使用XML格式定义或JSON格式定义。在RESTful API领域，版本管理目前有以下3中比较流行的方式：

(1)URI方式，即直接在统一资源标识符(uniform resource identifier，URI)中标记使用的哪个版本，无版本号默认使用最新版本。例如：http://h3c-cloud/api/v1.0/users/1234

(2)Request Parameter请求参数方式，即在每一个请求后添加一个version参数，表示请求的是哪个版本。例如：

http://h3c-cloud/api/clusters/1234？version＝3

(3)Header方式，即在HTTP请求的header中使用Media Type或者自定义字段标记该请求想获取的资源，同样可以不设置或设置通用的Media Type表示最新的API版本。

例如：version:v1.0或Accept:application/vnd.h3c.customer-v2+json

以上的3种实现方式一般都是需要API提供者自己开发和维护，在同一个API里面可能需要维护多个版本的代码，且一般为全量代码，这样做会导致代码的冗余，项目的臃肿。

上述API版本控制方式存在以下几方面的技术问题：

业务侵入性强，API提供者在开发新的业务需求时，还需要考虑对旧版本API的兼容问题，当业务逻辑复杂，版本过多时，会给API提供者带来很多的额外工作量。

造成代码冗余，为了避免多个版本的API之间互相影响的情况，不同版本的API即使逻辑大部分都一样，但还是得给每个版本的API提供单独的代码，导致了代码冗余，随着版本的增多，项目会变的越来越臃肿。

管理繁重，在微服务的体系下，不同的模块的业务往往会被分为不同的微服务来实现，由不同团队的人员来维护，不同团队之间可能会有各自的API版本的标准，当一个微服务体系比较庞大时，维护不同微服务的API版本会变得十分困难。