Control de versiones de servicios web y manejo del servidor

Question

Estoy tratando de diseñar una estrategia para el control de versiones de servicios web y cómo manejar versiones desde el punto de vista de SCM.

Estamos realizando servicios bottom-up (JAX-WS) y, por lo tanto, tenemos menos control sobre el esquema y no podemos seguir algunas versiones de esquema de las mejores prácticas. Mis pensamientos actuales son:

1) Los cambios importantes (no compatible hacia atrás):

• transmite al cliente a través de la API nueva URL de servicio (URL de versiones). Ej .:

http://com.example/v1/MyService

http://com.example/v2/MyService

Esto hace que en mi opinión menos problemas tanto para el cliente y los desarrolladores. El cliente simplemente actualiza la URL de los servicios (generalmente en un solo lugar) en lugar de actualizar todas las llamadas de servicio (como cuando se usa el control de versiones del nombre del servicio - MyServiceV1, MyServiceV2, ...).

• En el lado del servidor, esto se refleja etiquetando el servicio en SVN: MyService- [major]. [Minor] E.g. MyService-1,0

2) Los cambios menores (compatible hacia atrás):

• Esto es donde tengo más dudas. Algunas mejores prácticas implican la modificación del espacio de nombres del esquema, que a su vez implica la actualización para clientes compatibles.

• En el lado del servidor es claro como yo estoy usando la estrategia anterior ([service_name] - [importante] [menores].)

apreciarían opiniones sobre la estrategia anterior y sugerencias para el versiones menores.

Answer 1

Para la versión principal, creo que estás en el camino correcto, pero no usaría la "v", solo el número.

Para la versión de menor importancia que no veo que gran parte de un problema, si es compatible hacia atrás, entonces significa que el cambio estaba en el código pero no la interfaz (atmost se añadirá un nuevo método) para que solo necesita manejar las solicitudes que se están procesando para cuando esté a punto de implementar la nueva versión. Pero eso podría resolverse deshabilitando el servicio para su actualización justo después de que se haya procesado la última solicitud.

Si rompe los dos cambios menores, podría usar, para agregar métodos, la misma estrategia que dijo sobre las versiones principales.