更新或版本化Web服务的策略？

我很想听听有关如何处理不同版本的Web服务的最佳实践.

为了澄清一下,如果你有一些Web方法作为Web服务公开,那么你想要添加一个特性/功能,从而改变那些方法调用的签名,你如何处理这个方法不会破坏所有您当前致电该服务的客户？

您是否在不同的URL上部署服务？

你在方法名称中放了一个版本(MyMethod,MyMethodv2等等 - 呃..)

您是否将一个版本作为方法调用的一部分与参数列表一起传递？

有谁知道Google或亚马逊如何利用其广泛的Web服务库处理这种情况？

编辑:到目前为止,我在Oracle的这篇文章中找到了一些很好的信息.同时此博客条目上一些Java的细节是有益的.我仍然很想看到其他一些方法.

对Web服务进行版本控制的典型方法是让客户端指定所需的版本.您可以考虑简单约束,例如"> 2.0","<1.5"或"= 1.1".当然,您希望最大限度地减少支持的版本数量,以保证您的理智.如果客户端未指定版本,则假定为最新版本.

提供版本的技术各不相同.有些人主张使用URL,其他人鼓励使用标题,有些可能会将其作为api调用的参数包含在内.但是,几乎没有人会改变方法的名称.这相当于OSGi链接的"封装"或"命名空间"版本.这将使升级变得非常困难,并且阻碍人们进行升级,而不是对实际服务进行任何更改.

它还取决于您访问Web服务的方式.如果您正在使用REST,那么保持URL的清洁并使用标头是最有意义的(如果需要,将其作为查询参数进行破解是微不足道的).如果您正在使用SOAP/XMLRPC/whatever-RPC,那么将它放在URL中通常很好.

编辑5/2011 FWIW,虽然我不同意,但Apigee的博客建议将该版本放入URL中.

客户端如何指定版本通常很容易.更复杂的是如何同时运行所有版本.大多数语言都没有办法将同一个库/模块/类/函数的多个版本加载到同一个运行时环境中(无论是VM,进程还是拥有它的东西).您提供的OSGi链接是Java的解决方案,允许这样做.

在实践中,OSGi在大多数情况下都会过度杀伤.通常更容易将已弃用的请求代理到另一个服务器或进程.

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

我可以告诉你,创建doAPIFunction,doAPIFunctionV2和doAPIFunctionV3等的解决方案在我工作的地方只产生了令人头疼的问题.除此之外,缺乏清晰描述性的功能名称意味着各种各样的疯狂.

您需要清晰的API函数名称,如果api正在发生变化,目标是尽可能以向后兼容的方式尝试.我建议对入口点进行版本控制,这样每个入口点都支持一个稳定的API,如果有充分的理由改变语义,example.org /api-1.0/中的doFunction可能与example.org/api-2.0不同.