更新或版本化Web服务的策略？ [英] Strategies for updating or versioning web services?
问题描述
我有兴趣了解如何处理不同版本的Web服务的最佳做法。要澄清一点，如果您有一些Web方法作为Web服务公开，那么您要添加功能/功能，从而更改这些方法调用的签名，您如何处理这种情况，不会破坏您当前打电话给所有客户的方式？
您是否在不同的网址上部署服务？ / p>
您是否在方法名称本身放置一个版本（MyMethod，MyMethodv2等 - ugh ..）
有没有人知道Google或Amazon如何用广泛的Web Service库来处理这种情况呢？你是否知道方法调用的一部分以及参数列表？
编辑：到目前为止，我在这个来自Oracle的文章。另外某些Java细节上的这个博客条目很有用。我仍然很高兴看到其他一些方法。
Web服务版本化的典型方式是让客户端指定所需的版本。您可以允许简单约束，例如> 2.0，<1.5或= 1.1。当然，您希望最大限度地减少您自己的理智支持的版本数量。如果客户没有指定版本，您将承担最新的。
提供版本的技术各不相同。有些提倡使用URL，其他人鼓励头，有些可能会将其作为api调用的参数。几乎不会改变方法的名称。这相当于OSGi链接的package或namespace版本控制。这将使升级非常困难，并阻碍人们升级更多，而不是对实际服务的任何更改。
它还取决于您如何访问您的Web服务。如果您使用REST，那么保持URL干净和使用标头是最有意义的（如果需要的话）将其作为查询参数进行破解是很简单的。如果您使用的是SOAP / XMLRPC / whatever-RPC，那么将其放在URL中通常很好。
编辑5 / 2011 FWIW，尽管我不同意， Apigee的博客建议将该版本放在URL <一>。
客户端如何指定版本通常很简单。更复杂的是如何同时运行所有的版本。大多数语言没有将同一个库/模块/类/函数的多个版本加载到相同的运行时环境（无论是VM，进程还是您有什么）的方法。您提供的OSGi链接是Java的解决方案，以实现这一点。
在实践中，OSGi在大多数情况下将会过度使用。通常更容易将不建议的请求代理到另一个服务器或进程。
但是，版本服务的最佳方法是为其构建可扩展性和灵活性，以便他们保持向前和向后兼容。这并不意味着所有版本必须相互兼容，但连续的版本应该相互兼容。
I'm interested to hear the best practices on how different versions of web services are handled.
To clarify, if you've got some web methods exposed as a web service, then you want to add a feature/functionality and thus change the signature of those method calls, how do you handle this in a manner that doesn't break all of your clients who currently call the service?
Do you deploy the service on a different URL?
Do you put a version in the method name itself (MyMethod, MyMethodv2 etc. - ugh..)
Do you pass in a version as part of the method call along with a parameter list?
Does anyone know how Google or Amazon handle this scenario with their extensive Web Service library?
EDIT: So far I found some good info in this article from Oracle. Also this blog entry on some Java specifics was useful. I'm still curious to see some of the other approaches.
The typical way of versioning a web service is to have clients specify the version desired. You may allow for for simple constraints, like ">2.0", "<1.5", or "=1.1". Naturally, you want to minimize the number of supported versions for your own sanity. If a client doesn't specify a version, you assume the latest.
Techniques for providing the version vary. Some advocate using the URL, others encourage headers, some might include it as a parameter of the api call. Almost none would change the name of the method, though. Thats equivalent to the "package" or "namespace" versioning the OSGi link talks about. It'll make upgrading very difficult, and impede people from upgrading more so than any changes to the actual service.
It also depends on how you access your webservices. If you're using REST, then keeping the URL's clean and using headers makes the most sense (and it'd be trivial to hack it in as a query parameter, if need be). If you're using SOAP/XMLRPC/whatever-RPC, then putting it in the URL is usually fine.
Edit 5/2011 FWIW, though I disagree, Apigee's blog recommends putting the version in the URL.
How the client specifies the version is usually pretty easy. Whats more complicated is how you run all the versions concurrently. Most languages don't have a way of loading multiple versions of the same library/module/class/function into the same runtime environment (be it a VM, process, or what have you). The OSGi link you provided is Java's solution to allow this.
In practice, OSGi will be overkill for most situations. Its usually easier to proxy deprecated requests to another server or process.
The best way to "version" your services, though, is to build extensibility and flexibility into them so they remain forwards and backwards compatible. That doesn't mean that all versions must be compatible with each other, but consecutive versions should be compatible with each other.
这篇关于更新或版本化Web服务的策略？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
