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

Question

我正在尝试为Web服务版本控制以及如何从SCM角度处理版本。

我们正在执行自下而上（JAX-WS）服务，因此对模式的控制较少，无法遵循最佳实践的某些模式版本控制。我现在的想法是：通过新服务的网址（URL版本）传输到API客户

• ：

  1）重大变化（非向后兼容）。例如为：

http://com.example/v1/MyService

http://com.example/v2/MyService

这将导致在我看来，为客户和开发商都少些麻烦。客户端只是更新服务URL（通常在一个地方），而不是更新所有的服务调用（例如使用服务名称版本 - MyServiceV1，MyServiceV2，...）。

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

2）的微小变化（向后兼容）：

• 这是我有更多怀疑。一些最佳实践涉及修改模式名称空间，这反过来又涉及为兼容客户进行升级。

• 在服务器端很清楚，因为我使用上述策略（[SERVICE_NAME] - [大] [次要]）。

希望了解对于上述的策略的意见和建议次要版本。

Answer 1

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

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

如果你打破了你可以使用的两个小的改变，对于方法增加，你可以使用与你对主要版本所说的相同的策略。