Cómo admitir diferentes versiones de API

Navega tus respuestas
13

Estoy escribiendo una API de Rest y me pregunto cuál es la mejor manera de manejar la compatibilidad con las diferentes versiones. Con esto no me refiero a cómo definir un URI como V2 o V3, sino más bien cómo estructurar el código dado que debería:

  • Admite varias versiones al mismo tiempo, por ejemplo. V1 & V2 & Las URI V3 deben estar activas al mismo tiempo. Retiraría V1 cuando diga V4 para restringir la cantidad admitida en cualquier momento.
  • Evita la duplicación de código tanto como sea posible
  • Facilita la adición de cambios ininterrumpidos a una versión, sin que tenga impacto en otras versiones

Parece que hay pocos enfoques que podrían adoptarse:

  • Use Git para controlar las versiones, con una rama para las diferentes versiones (y las versiones antiguas no tienen esencialmente ningún nuevo trabajo de desarrollo). Esto significaría que no habrá duplicación de código, ya que solo la última versión está en el código, pero las versiones anteriores tendrían que trabajar con la nueva versión de la base de datos hasta que se retiren.

  • Duplique el código para que cada versión se maneje en la misma aplicación y tenga una ruta de código totalmente separada, pero esto significaría mucha duplicación

  • Reutilice una gran cantidad de código en las versiones, pero esto dificultaría el mantenimiento, ya que es más probable que el cambio de una versión tenga un impacto en una versión anterior

¿Existe alguna práctica recomendada para tratar este problema ya que todas las opciones parecen tener sus propios problemas?

    
pregunta Andy Davies 11.03.2014 - 22:45

3 respuestas

5

Haz esto:

  

Reutilice una gran cantidad de código en las versiones, pero esto dificultaría el mantenimiento, ya que es más probable que el cambio de una versión tenga un impacto en una versión anterior

pero no rompas las versiones anteriores.

Debería tener pruebas que verifiquen que todas las versiones compatibles funcionan correctamente. Si no tiene esas pruebas, primero debe crearlas para cubrir cualquier código que esté cambiando.

    
respondido por el kevin cline 11.03.2014 - 23:43
2

Una combinación de usar sucursales de lanzamiento de GIT (o unir cada versión en un repositorio separado) para admitir y mantener las versiones antiguas de la API y posiblemente tener algún código reutilizable que se puede compartir como una dependencia, como una biblioteca común, es lo más Probablemente el camino a seguir. Así que cada versión de la API sería un artefacto desplegable por separado. Esto permite flexibilidad para que, por ejemplo, la API V1 pueda depender de los commons V1, mientras que las API V2, V3, V4 pueden depender de los commons V2. Esto sería lo más fácil y limpio desde una perspectiva de desarrollo, ya que su base de código no se multiplica con cada nueva versión, en lugar de eso, cada versión está aislada en su propio proyecto / base de código y solo se ocupa de sí misma.

Otra razón para implementar artefactos separados es que puede haber problemas transversales como un mecanismo de seguridad, o marcos / bibliotecas como el marco de inyección de dependencias que podría cambiar en las versiones más nuevas de la API y crearía muchas dificultades para admitir versiones anteriores. API si todos viven en la misma base de código (y Classloader en tiempo de ejecución, si es Java).

Cada enfoque, ya sea una rama por versión o una base de código duplicada monolítica, siempre tendrá el problema de un punto de integración común (como la base de datos o un esquema de caché distribuido) que necesita cambiar. Las API de versiones anteriores pueden requerir algún tipo de mantenimiento para trabajar con esos cambios, o la introducción de algunas otras herramientas (como vistas de bases de datos) para ayudar a la compatibilidad. Esto puede ser una dificultad inevitable dependiendo de la naturaleza de sus cambios.

    
respondido por el PaulMooney 08.01.2015 - 19:21
0

No sé qué tan diferentes son los resultados de sus versiones de API, pero podría tener una capa de compatibilidad en el medio que puede alternar entre las versiones y rellenar espacios o traducir datos.

Dicho esto, por lo general, nunca se resuelve uno a uno, por lo que un diseño tipo interruptor o máquina de estado me ha ayudado con este problema.

    
respondido por el Zach Leighton 12.03.2014 - 02:28

Lea otras preguntas en las etiquetas

¿Cuál es un buen diseño para permitir la compatibilidad con versiones anteriores de archivos entre diferentes versiones de software? ¿Cómo evito escribir muchas funciones de paso en un contenedor?