Best practice per compatibilità con le versioni precedenti delle API

Question

Sto lavorando a un'app per iPhone/iPad/Android che comunica con un'API JSON.

La prima versione della versione dell'app è completa e ora sono in corso ulteriori fasi di sviluppo. Nelle fasi aggiuntive, l'app deve essere integrata con una nuova versione dell'API e consentire all'utente l'accesso a funzionalità aggiuntive quali nuove schermate o comportamenti modificati all'interno di schermate esistenti. L'app deve tuttavia essere retrocompatibile con le versioni precedenti dell'API.

Qual è la migliore pratica per affrontare un simile requisito? potevo di poteva fare controlli in tutto il codice:

if (APIVersion == 1) { 

} else if (APIVersion == 2) { 

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

}... 

Ma io sono preoccupato per la scalabilità di questo approccio. Mi viene in mente il metodo di produzione, ma non sono sicuro di quanto mi avrebbe portato.

Grazie, Mark

Answer 1

rilascio di una nuova versione API è un rarissimo cosa . Di solito è possibile ottenere la retrocompatibilità semplicemente aggiungendo nuovi parametri opzionali o nuovi metodi. Per esempio, se tu fossi metodo denominato search, ma ora si sono insoddisfatti del modo in cui funziona, si può trattare con esso in vari modi:

• Se il cambiamento è semplice è possibile aggiungere un nuovo parametro mode che il valore predefinito è mode1 (quindi è retrocompatibile). Se l'utente fornisce mode2, lo si rileva con una condizione if corretta come si è proposto. (Di solito, si può pensare ad un nome migliore di "mode".)

• Se la modifica è grande, è possibile aggiungere un nuovo servizio search2 che utilizza la nuova interfaccia. Quindi contrassegni il metodo search come deprecato (ma ancora funzionante e compatibile con le versioni precedenti). Di solito quando lo fai, puoi rifare il codice nel tuo codice in modo tale che quasi tutta la logica è all'interno del metodo search2, e il tuo vecchio metodo search chiama search2 internamente con parametri modificati (e riformatta i risultati in modo appropriato) . Se lo fai correttamente, non avrai più bisogno di cambiare il metodo search. Quando modifichi le tue tabelle, ecc., Devi solo modificare search2.

Il mio punto è, evitare di rilasciare la versione N+1 -st di un'API.Tale versione importante implica importanti cambiamenti in ALL dei tuoi metodi, non solo uno. Molte API importanti non hanno mai rilasciato la versione 2 della loro API, usano ancora la versione 1, ne modificano leggermente le parti, come nell'esempio sopra.

Se siete assolutamente sicuri di rilasciare la versione N+1 -st di voi API, creare nuovi punti di ingresso per TUTTI dei vostri metodi. Se si dispone di una cartella denominata services, creare una nuova denominata services-v2. Riforma il tuo codice services in modo che utilizzi il massimo di services-v2. Se pensi che sia eccessivo, allora penso che non hai ancora bisogno della versione N+1 -st della tua API.

BTW, non confondere le API centralizzate (come Google Maps) con quelle distribuite (come Android). Android rilascia continuamente nuove versioni dell'API, perché ci sono miliardi di server Android (ogni dispositivo Android è uno solo) e non possono essere semplicemente aggiornati in remoto da Google. La prossima versione di Android è ancora retrocompatibile con la precedente, il numero viene aumentato solo per indicare nuove funzionalità. Es. Puoi ancora eseguire app create per Android 3.0 su Android 7.0 (l'utente potrebbe ricevere alcuni avvisi in più, ma l'app verrà eseguita). Gli sviluppatori di app Android utilizzano questi numeri per descrivere i "requisiti minimi" per le loro app. Considerando che le API centralizzate di solito aumentano il loro numero di versione per indicare un'importante modifica incompatibile con le versioni precedenti.

Answer 2

Credo che si dispone già di una separazione degli interessi. Voglio dire, ottenere i dati per la tua app avviene solo attraverso il Modello (per esempio).

Quindi è sufficiente modificare il modello.

Quello che suggerisco è che esiste un solo punto di accesso: il file "router". Questo file controlla la versione dell'API necessaria e carica il file corretto. In questo modo, ottieni diversi file per ciascuna API. Il file "router" non sarà molto grande e ogni nuova versione dell'API avrà il proprio file, quindi non dovrai mischiare tutto.

Ad esempio, nel file "router":

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; 
    } 
}