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

我正在尝试设计一种 Web 服务版本控制策略以及如何从 SCM 的角度处理版本。

我们正在做自下而上（JAX-WS）服务，因此对架构的控制较少，并且无法遵循最佳实践的某些架构版本控制。我目前的想法是：

1) 主要变化（不向后兼容）：

• 通过新服务 URL（URL 版本控制）传输到 API 客户端。例如。：

http://com.example/v1/MyService http://com.example/v1/MyService

http://com.example/v2/MyService http://com.example/v2/MyService

我认为这减少了客户和开发人员的麻烦。客户端仅更新服务 URL（通常在一处），而不是更新所有服务调用（例如使用服务名称版本控制时 - MyServiceV1、MyServiceV2，...）。

• 在服务器端，这通过在 SVN 中标记服务来反映：MyService-[major].[minor]我的服务-1.0

2) 小改动（向后兼容）：

• 这是我比较疑惑的地方。一些最佳实践涉及修改架构命名空间，这又涉及兼容客户的升级。

• 在服务器端很清楚，因为我使用上面的策略（[service_name]-[major].[minor]）

感谢您对上述策略的意见以及对次要版本的建议。

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

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

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