Web服务版本控制和服务器端处理

Question

我正在尝试为Web服务版本控制制定策略,以及如何从SCM的角度处理版本.

我们正在进行自下而上(JAX-WS)服务,因此对模式的控制较少,并且无法遵循最佳实践的某些模式版本.我目前的想法是:

1)重大变化(非向后兼容):

• 通过新服务URL(URL版本控制)传输到API客户端.例如:

HTTP://com.example/v1/MyService

HTTP://com.example/v2/MyService

在我看来,这对客户和开发人员来说都不那么麻烦.客户端只更新服务URL(通常在一个地方)而不是更新所有服务调用(比如使用服务名称版本 - MyServiceV1,MyServiceV2,...).

• 在服务器端,这通过在SVN中标记服务来反映:MyService- [major].[minor]例如MyService-1.0

2)微小变化(向后兼容):

• 这是我有更多疑虑的地方.一些最佳实践涉及修改模式命名空间,而后者又涉及升级兼容客户.

• 在服务器端清楚,因为我正在使用上面的策略([service_name] - [major].[minor])

对于上述策略的意见和对次要版本控制的建议表示赞赏.

Answer 1

对于主要版本，我认为您走在正确的道路上，但我不会使用“v”，而只是使用数字。

对于次要版本，我没有看到太大的问题，如果它是向后兼容的，那么这意味着更改是在代码上而不是接口上（最多会添加一个新方法），所以你只需要处理您即将部署新版本时正在处理的请求。但这可以通过在处理最后一个请求后立即禁用更新服务来解决。

如果您破坏了两个小的更改，则可以使用与您所说的主要版本相同的策略来添加方法。