Existe la necesidad de modificar el contrato existente (cargas útiles de petición / respuesta), de un resorte de arranque Microservice, que están rompiendo esencialmente cambios (no compatible con versiones anteriores). Y es esencial para apoyar tanto a las versiones del contrato hasta algún tiempo - hasta el momento todas las actualizaciones de los clientes a sí mismos a la nueva versión.
Con el fin de lograr este objetivo, se ha decidido utilizar el URL de versiones de estrategia (como / v1 / {} de recursos y / v2 / {} de recursos).
Ahora, la pregunta es ¿cuál es la mejor manera de implementar esto en código? A continuación se presentan las dos soluciones propuestas
Se ramifican por un (versión v1 / ) de código y mantenerlo separado hasta que se apoya esta versión. Esto significa esencialmente que el corte de la rama de maestro y build / despliegue de esta rama y mantener dos instancias del mismo servicio cada apoyo v1 y v2 versiones respectivamente.
En la misma rama principal, introducir un paquete separado (como service.api.v2.request ) y poner todas las clases de la solicitud de API carga útil / respuesta allí y introducir un nuevo controlador de punto final a soporte ( / v2 ). Este enfoque permite instancia única para soportar tanto las versiones.
¿Cuál de lo anterior es un mejor enfoque? O hay cualquier otro estándar / mejores alternativas para lograr esto? ¿El resorte de arranque proporciona ninguna fuera de la caja de soporte para este tipo de necesidades?
Depende de cómo muchos puntos en común que hay detrás del controlador. Si las versiones son significativamente diferentes de todo el camino hasta el final en ese entonces tal vez diferentes ramas son más fáciles de trabajar, pero si las principales diferencias están en los caminos del controlador y la entrada y salida de objetos involucrados en esos métodos, entonces es probable que 2 ramas conducen al dolor de la aplicación de cambios en ambos, y recordando a hacerlo cada vez - es el tipo de situación en la que tarde o temprano, no se alcanzará una solución importante.
Todo es un equilibrio, y hay que sopesar el coste de mantenimiento de los enfoques en su caso, en términos de tiempo y esfuerzo, y también el riesgo de errores, así como el costo de las implementaciones separadas.