La mejor manera de administrar actualizaciones en una aplicación cliente/servidor iOS

Question

Tengo una pregunta logística: estoy tratando de encontrar la mejor manera de administrar las API que no están sincronizadas con una aplicación. La mejor manera de explicarlo es con un ejemplo:

Digamos que MyApp Versión 1.0 publica una API "submit_feedbacK" que requiere first_name, last_name y email.

Luego envío la versión 2.0 de MyApp a la tienda de aplicaciones. Esa versión está diseñada para publicar first_name, last_name, gender y email en la API. Todos estos son campos obligatorios en la API.

El problema que tengo: - Si actualizo la API antes de la nueva aplicación es en vivo, se romperá Versión 1.0 - Si espero hasta la versión 2.0 es en directo y de forma remota paralizar 1.0, tengo que medir el tiempo correctamente.

Voy a adivinar que la "respuesta correcta" es mantener dos API diferentes. Pero si ambas API se publican en la misma base de datos en vivo, eso hace que las cosas sean un poco incómodas.

¿Alguien tiene sugerencias sobre cómo modelar esto?

Answer 1

Esta pregunta puede compartir algunos aspectos con iOS consuming API design.

La respuesta correcta es definitivamente proporcionar dos API (al menos por un corto período de tiempo mientras los usuarios se ajustan). No es necesario que mantenga dos versiones al mismo tiempo, ya que una vez que se lanza una versión más nueva, puede mantenerla y simplemente proporcionar la anterior para usuarios heredados. Los únicos cambios reales que puede tener que hacer son cosas como parches de seguridad o problemas importantes. Los cambios importantes (como la decisión de reestructurar toda su base de datos) pueden llevar a que la versión anterior no funcione, sin embargo, la actualización a las versiones más nuevas de la API debe diseñarse para permitir que las versiones anteriores sigan funcionando.

La otra pregunta a la que te he vinculado brinda una respuesta sobre cómo puedes tener diferentes versiones de tu aplicación accediendo a la versión correcta de la API.

Otra nota es que puede ser más fácil para usted (dependiendo de qué marco está utilizando) diseñar sus API como motores o subapps, y simplemente montarlos en diferentes puntos finales. Sé que esto se puede hacer fácilmente en Rails usando motores, y en Node with Express usando app.use() con sub-aplicaciones.

Answer 2

Utilizaría un punto de servicio web/http para la comunicación con su aplicación. Si prefiere mantener la misma URL en todas las versiones de la aplicación, incluya un número de versión en todas las solicitudes/publicaciones en el servidor para que sepa cómo manejarlas. Esto también facilitará el desarrollo y las pruebas ya que las nuevas versiones pueden probar contra la nueva API en el servidor.

De modo que en cualquier función puede llamar al servicio web/servidor y agregar una sola variable con el número de versión. un BYTE debería ser suficiente, ya que creo que podrías comenzar de nuevo y "matar soporte para v1.0" una vez que aciertes 256 versiones de la misma función (si es que alguna vez).

Una vez que el servidor recibe una solicitud/publicación con datos, puede simplemente codificar una estructura de conmutador/caso simple en la API del servidor para que soporte funcione para ambas versiones.

Si lo hacen de manera similar, pero por ej. intercambia los parámetros o algo así, puede manejar todos estos servidores y se puede mantener BAL/DAL (estructura de n niveles) en la parte del servidor de la solución.

Btw.mi respuesta no es solo para iOS o dispositivos inteligentes, sino solo un enfoque de cliente/servidor para una configuración de producción "en proceso" en la que todo tiene que estar en línea, mientras se está desarrollando y manteniendo.

Espero que tenga sentido, de lo contrario, coméntelo y trataré de explicarlo más.

Answer 3

solo para FYI, utilizo CodeIgniter. Estoy usando el controlador REST proporcionado en https://github.com/philsturgeon/codeigniter-restserver. Terminé terminando por establecer diferentes puntos finales para cada versión. Básicamente verificaría un nuevo repositorio para cada lanzamiento y lo colocaría en un directorio único. (es decir, http://www.mysite.com/1.0/api/method, http://www.mysite.com/1.1/api/method, etc.) Tratar de mantener múltiples versiones de una API bajo una base de código sonaba demasiado aterrador. Al menos cuando lancé una versión, sabría que está bloqueada en piedra y no tengo que preocuparme por romperla. (Nota: tuve que usar un tweak .htaccess especial para obtener varias instancias de CodeIgniter ejecutándose desde el mismo dominio. Puedo compartirlo si lo desea)