更新或版本化web服务的策略?

对web服务进行版本控制的典型方法是让客户端指定所需的版本。您可以考虑简单的约束,如“>2.0”、“<1.5”或“=1.1”。当然,为了您自己的理智,您希望尽量减少支持的版本数量。如果客户端未指定版本,则假定为最新版本。

提供版本的技术各不相同。有些人主张使用URL,有些人鼓励使用标题,有些人可能将其作为api调用的参数。不过,几乎没有人会更改该方法的名称。这相当于OSGi链接所说的“包”或“名称空间”版本。这将使升级变得非常困难,并且比实际服务的任何更改更阻碍人们升级。

这还取决于您访问Web服务的方式。如果您使用的是REST,那么保持URL的干净并使用标题是最有意义的(如果需要的话,将其作为查询参数进行黑客攻击也很简单)。如果您使用的是SOAP/XMLRPC/whatever-RPC,那么将其放入URL通常是可以的。

编辑5/2011 FWIW,虽然我不同意, Apigee's blog recommends putting the version in the URL .

客户端如何指定版本通常非常简单。更复杂的是如何同时运行所有版本。大多数语言都无法将同一库/模块/类/函数的多个版本加载到同一运行时环境中(无论是VM、进程还是其他)。您提供的OSGi链接是Java的解决方案。

在实践中,OSGi在大多数情况下都会被过度使用。将不推荐使用的请求代理到另一个服务器或进程通常更容易。

不过,“版本化”您的服务的最佳方法是为其构建可扩展性和灵活性,以便它们保持向前和向后兼容。这并不意味着所有版本都必须相互兼容,但连续的版本应该相互兼容。

我可以告诉你,创建doAPIFunction、doAPIFunctionV2和doAPIFunctionV3等的解决方案在我工作的地方只会带来麻烦。此外,缺少清晰的描述性函数名意味着各种各样的疯狂。

若方法的签名像另一个新参数一样改变,那个么为什么不能将其设置为可选的呢?但如果现有参数数据类型已更改,则不适用。

如果这显然是错误的,请投票否决

一旦您编写了一个Web服务,您就与客户签订了一份合同,这就是您将支持的内容。

除此之外,您最好只编写一个新方法,这样您可能会有几个类似的函数名,但不同的版本会有所不同。

在名称中添加一个版本号似乎对我来说最合适,因为它可以清楚地显示什么是旧的,并且您可以使用AOP更轻松地记录webservice方法的旧版本。

缓解这种情况的一种方法是按合同编码,并在石头上设置接口。你永远不可能真正 改变 但是,您可以重载函数签名。考虑.NET API。它不赞成某些方法,但它们继续工作,因为围绕它们编写的程序可能会中断。该服务的新版本可能会在不同的URI(v2.webservice.com)上公开,以给它一个新的路线图,v1需要继续得到支持。