Mejores prácticas para la compatibilidad con versiones anteriores de API

Question

Estoy trabajando en una aplicación de iPhone/iPad/Android que se comunica con una API JSON.

El primer lanzamiento de la versión de la aplicación está completo y ahora se están llevando a cabo otras fases de desarrollo. En las fases adicionales, la aplicación debe integrarse con una nueva versión de la API y permitir que el usuario acceda a características adicionales, como nuevas pantallas o un comportamiento modificado dentro de las pantallas existentes. Sin embargo, la aplicación necesita estar al revés con las versiones anteriores de la API.

¿Cuál es la mejor práctica para abordar ese requisito? que pude podía hacer controles durante el código:

if (APIVersion == 1) { 

} else if (APIVersion == 2) { 

} else if (APIVersion == ....) { 

}... 

Pero estoy preocupado por la escalabilidad de este enfoque. Me viene a la mente el método de fábrica, pero no estoy seguro de lo lejos que me llegaría.

Gracias, Marcos

Answer 1

lanzamiento de una nueva versión de la API es una cosa muy rara. Por lo general, puede lograr compatibilidad con versiones anteriores simplemente agregando nuevos parámetros opcionales o nuevos métodos. Por ejemplo, si usted hubiera método denominado search, pero ahora no está satisfecho con la forma en que funciona, es posible tratar con él de varias maneras:

• Si el cambio es simple puede agregar un nuevo parámetro mode cuales el valor predeterminado es mode1 (por lo que es compatible con versiones anteriores). Si el usuario suministra mode2, lo detecta con una condición adecuada de if tal como se propuso usted. (Además, generalmente puede pensar en un nombre mejor que "modo").

• Si el cambio es grande, puede agregar un nuevo servicio search2 que utiliza la nueva interfaz. Luego marque el método search como obsoleto (pero sigue funcionando y es compatible con versiones anteriores). Generalmente cuando haces esto, puedes refactorizar tu código de tal manera, que casi toda la lógica está dentro del método search2, y tu antiguo método search llama internamente al search2 con parámetros modificados (y reformatea los resultados apropiadamente) . Si hace esto correctamente, ya no necesitará cambiar el método search. Cuando modifique sus tablas, etc., solo necesitará modificar search2.

Mi punto es, evitar la liberación de N+1 versión -st de una API.Tal versión grande implica cambios importantes en TODOS de sus métodos, no solo uno. Muchas API principales nunca lanzaron la versión 2 de su API, todavía usan la versión 1, solo modifican partes de ella, como en el ejemplo anterior.

Si usted es absolutamente seguro sobre la liberación deN+1 versión -st de ustedes API, crear nuevos puntos de entrada para TODO de sus métodos. Si tenía una carpeta llamada services, cree una nueva llamada services-v2. Refactorice su código services para que utilice la mayor parte de services-v2. Si crees que es excesivo, entonces creo que no necesitas N+1, la versión más reciente de tu API.

Por cierto, no confundas las API centralizadas (como Google Maps) con las distribuidas (como Android). Android lanza nuevas versiones de API todo el tiempo, porque hay miles de millones de servidores de Android (cada dispositivo Android es uno), y no todos pueden ser actualizados de forma remota por Google. La próxima versión de Android aún es compatible con la anterior, el número aumenta solo para indicar nuevas funciones. P.E. Aún puede ejecutar aplicaciones creadas para Android 3.0 en Android 7.0 (el usuario podría recibir algunas advertencias adicionales, pero la aplicación se ejecutará). Los desarrolladores de aplicaciones de Android usan estos números para describir los "requisitos mínimos" para sus aplicaciones. Considerando que, las API centralizadas generalmente aumentan su número de versión para indicar un importante cambio retrocompatible.

Answer 2

supongo que ya tiene una separación de intereses. Es decir, obtener los datos de su aplicación solo se hace a través del Modelo (por ejemplo).

Así que solo tiene que cambiar el modelo.

Lo que sugiero es que solo hay un punto de entrada: el archivo "enrutador". Este archivo comprueba la versión de API necesaria y carga el archivo correcto. De esta forma, obtienes diferentes archivos para cada API. El archivo "enrutador" no será muy grande, y cada nueva versión de API tendrá su propio archivo, por lo que no se mezclará todo.

Por ejemplo, en el archivo "enrutador":

function dispatch() { 
    switch (APIVersion) { 
    case 1: 
     use('file.1.ext'); 
     break; 
    case 2: 
     use('file.2.ext'); 
     break; 
    case 3: 
     use('file.3.ext'); 
     break; 
    } 
}