Come supportare diverse versioni API

Sto scrivendo un'API Rest e mi chiedo come gestire al meglio il supporto delle diverse versioni. Con questo non intendo come definire un URI come V2 o V3, ma piuttosto come strutturare il codice dato che avrebbe bisogno di:

• Supporta più versioni contemporaneamente, ad es. Gli URI V1 e V2 e V3 devono essere attivi contemporaneamente. Ritirerei V1 quando dico che V4 arriva al fine di limitare la quantità supportata in qualsiasi momento.
• Evita quante più duplicazioni di codice possibile
• Semplifica l'aggiunta di modifiche senza interruzioni a una versione, senza che ciò influisca su altre versioni

Sembrerebbe che ci siano pochi approcci che potrebbero essere adottati:

• Usa Git per controllare le versioni, con un ramo per le diverse versioni (e le versioni precedenti essenzialmente non hanno fatto alcun nuovo lavoro di sviluppo su di esso). Ciò significherebbe non duplicare il codice poiché nel codice è presente solo l'ultima versione, ma le versioni precedenti dovrebbero funzionare con la nuova versione del DB fino a quando non vengono ritirate.

• Codice duplicato in modo che ogni versione sia gestita nella stessa applicazione e abbia un percorso di codice totalmente separato, ma ciò significherebbe un sacco di duplicazioni

• Riutilizzare molto codice tra le versioni, ma ciò renderebbe più difficile la manutenzione poiché la modifica di una versione ha maggiori probabilità di influire su una versione precedente

C'è qualche buona pratica per affrontare questo problema in quanto tutte le opzioni sembrano avere i propri problemi?

Fai questo:

Riutilizzare molto codice tra le versioni, ma ciò renderebbe più difficile la manutenzione poiché la modifica di una versione ha maggiori probabilità di influire su una versione precedente

ma non rompere le versioni precedenti.

È necessario disporre di test per verificare che tutte le versioni supportate funzionino correttamente. Se non hai questi test, dovresti prima crearli per coprire qualsiasi codice che stai modificando.

Una combinazione di utilizzo dei rami di rilascio GIT (o fork di ogni versione in un repository separato) per supportare e mantenere le vecchie versioni API e possibilmente avere un codice riutilizzabile che può essere condiviso come dipendenza, come una libreria comune, è probabilmente il modo andare. Quindi ogni versione dell'API sarebbe un artefatto distribuibile separatamente. Ciò consente flessibilità in modo che, ad esempio, l'API V1 possa dipendere dai beni comuni V1, mentre le API V2, V3, V4 possono dipendere dai beni comuni V2. Questo sarebbe il più semplice e pulito dal punto di vista dello sviluppo poiché la tua base di codice non si moltiplica con ogni nuova versione, invece ogni versione è isolata nel suo progetto / base di codice e si occupa solo di se stessa.

Un altro motivo per distribuire artefatti separati è che potrebbero esserci preoccupazioni trasversali come un meccanismo di sicurezza o framework / librerie come il framework di iniezione delle dipendenze che potrebbero cambiare nelle versioni più recenti dell'API e creerebbero molte difficoltà a supportare API più vecchie se tutti vivono nella stessa base di codice (e Classloader in fase di esecuzione, se è Java).

Ogni approccio, sia esso un ramo per versione o una base di codice duplicata monolitica, avrà sempre il problema di un punto di integrazione comune (come il DB o uno schema di cache distribuita) che deve essere modificato. Le API della versione precedente potrebbero richiedere un tipo di manutenzione per funzionare con tali modifiche o l'introduzione di altri strumenti (come le visualizzazioni del database) per favorire la compatibilità. Questa potrebbe essere un'inevitabile difficoltà a seconda della natura delle modifiche.

Non so quanto siano diversi i risultati rispetto alle tue versioni API, ma potresti avere un livello di compatibilità nel mezzo che può passare da una versione all'altra e riempire gli spazi vuoti o tradurre i dati.

Detto questo - di solito non risolve mai uno a uno - quindi un interruttore o una progettazione del tipo di macchina mi ha aiutato con questo problema.