[发明专利]一种网络应用程序接口升级的方法及系统

说明书

技术领域

本申请涉及互联网领域，尤其涉及一种网络应用程序接口升级的方法及系统。

背景技术

在开放平台领域，Web API（网络应用程序接口）一旦发布上线后，会被大量的外部应用调用，而发布后的Web API由于新增功能或者修复缺陷等原因不可避免的需要进行升级，然而，对于已发布的Web API进行升级，会带来以下三个问题：1）对于兼容性升级，如何做到对外部应用的透明性，即，在不强迫外部应用改变原有Web API调用方式的前提下，使兼容性升级自动生效，同时对于内部网关来说，又可以区分兼容性升级前后的Web API，以便做不同的内部处理；2）对于非兼容性升级，如何做到升级前和升级后的Web API的隔离性，既不影响那些已经调用升级前的Web API的外部应用的正常运行，同时，又能由外部应用自行选择是否调用升级后的Web API；3）如何做到线上测试环境和线上正式环境的Web API隔离以及切换，即，在线上测试环境中，可以使用线上真实的请求对升级后的Web API进行测试验证，而在测试期间，线上正式环境仍然使用升级前的Web API，测试通过发布后，线上正式环境使用的Web API自动切换为升级后的版本。

目前的Web API升级方法主要有以下三种方案：第一种是升级后采用新的Web API名称；第二种是给Web API加一个版本属性，升级后更新版本号，应用调用时需要同时传递Web API名称和版本号两个信息；第三种是升级后不改变Web API的任何标示信息，包括名称和版本等。

现有的技术方案的第一种和第二种，因为每次升级后都会更新Web API的标示信息（第一种改变名称信息，第二种改变版本信息），而Web API的标示信息恰恰包含在外部应用的请求参数中，因此，升级后会影响已有应用对Web API原有的使用方式。例如，对于现有的第一种方案，由于每次Web API升级后都会修改名称，这会导致Web API名称泛滥，并且，有些Web API的名称代表了该Web API特定的功能、作用等，改变名称后，无法体现出Web API的内在含义。对于现有的第二种方案，例如，原来的外部应用调用方式如下：https://openapi.xxxxx.com/gateway.do?method=abcd.efgh.hijk&version=1.0&us er_id=2012123456789123，Web API进行兼容性升级后版本号变为2.0，那么对于已有的应用，如果不能接受这个缺陷，就必须将原来的Web API调用参数中的版本号由1.0改为2.0，即，调用方式改变为：https://openapi.xxxxx.com/gateway.do?method=abcd.efgh.hijk&version=2.0&us er_id=2012123456789123。而这对于兼容性升级来说，是不可接受的，因为一旦该Web API已被大量的外部应用使用后，再强迫所有的这些应用进行改造的代价是巨大的。

现有方案的第三种，对于兼容性升级，虽然对外部应用来说是透明的，但由于升级前和升级后的Web API的标示信息是完全相同的，对内部的网关来说升级前后的Web API是无法区分的，网关无法针对升级前和升级后的Web API做不同的处理，例如，网关无法将升级前和升级后的Web API路由到不同的目标系统。另外，兼容性升级前后的Web API的返回结果可能会出现不一样，譬如升级后的Web API的返回结果增加了一个返回属性，外部应用的开发者可能就会感到疑惑，因为开发者从返回结果中无从知道Web API是否进行过兼容性升级，不利于快速排查问题；而对于非兼容性升级，是不可接受的。例如，某Web API返回的结果里包含有用户的邮箱地址属性，原来这个属性是一个字符串类型：{“email”:”xxx@x.com”}，应用以字符串的方式使用该属性。之后，由于用户可以有多个邮箱地址，因此对该Web API进行非兼容性升级，将邮箱地址属性改为列表类型{“email”:[“xxx@x.com”,“yyy@x.com”]}，那么就会破坏原来以字符串方式使用该属性的应用的运行。

同时，由于线上测试环境和线上正式环境使用的是同一份数据，采用上述三种方法对Web API进行升级后，会立即同时影响线上测试环境和线上正式环境，因此无法做到线上测试环境和线上正式环境之间的Web API隔离，一旦升级后的Web API引发比较严重的缺陷，会给线上正式环境带来很大的影响。

发明内容