问题
I am trying to devise a strategy for Web Services versioning and how to handle versions from a SCM point of view.
We are doing bottom-up (JAX-WS) services, and therefore have less control over the schema and can't follow some schema versioning of the best practices. My current thoughts are:
1) Major changes (non-backwards compatible):
- Transmitted to the API client via new service URL (URL versioning). E.g.:
http://com.example/v1/MyService
http://com.example/v2/MyService
This causes in my opinion less hassle for both the client and developers. The client just updates the services URL (generally in one place) rather than updating all the service calls (like when using service name versioning - MyServiceV1, MyServiceV2,...).
- In the server side, this is reflected by tagging the service in SVN: MyService-[major].[minor] E.g. MyService-1.0
2) Minor changes (backwards-compatible):
This is where I have more doubts. Some best practices, involve modifying the schema namespace which in turn involves upgrading for compatible customers.
In the server-side is clear as I am using the strategy above ([service_name]-[major].[minor])
Would appreciate opinions on the strategy above and suggestions for the minor versioning.
回答1:
For the major version I think that you are in the right path, I wouldn't use the "v" though, just the number.
For the minor version I don't see that much of a problem, if it is backwards-compatible then it means that the change was on the code but not the interface (atmost it will add a new method) so you only need to handle the requests that are being processed by the time you are about to deploy the new version. But that could be handled by disabling the service for update right after the last request has been processed.
If you break the two minor changes you could use, for method addition, the same strategy as you said about the major versions.
来源：https://stackoverflow.com/questions/3952910/web-services-versioning-and-server-side-handling