Come supportare diverse versioni API

Naviga le tue risposte
13

Sto scrivendo un'API Rest e mi sto chiedendo 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 sarebbe necessario:

  • Supporta più versioni contemporaneamente, ad es. V1 e amp; V2 e amp; Gli URI V3 devono essere attivi allo stesso tempo. Ritirerei V1 quando dico V4 entra per limitare l'importo supportato in qualsiasi momento.
  • Evita il più possibile la duplicazione del codice
  • Semplifica l'aggiunta di modifiche senza interruzioni a una versione, senza influire sulle altre versioni

Sembrerebbe che ci siano pochi approcci che potrebbero essere presi:

  • Usa Git per controllare le versioni, con un ramo per le diverse versioni (e le vecchie versioni essenzialmente non hanno alcun nuovo lavoro di sviluppo fatto su di esso). Ciò significherebbe la duplicazione del codice in quanto solo la versione più recente è nel codice, ma le versioni precedenti avrebbero bisogno di lavorare con la nuova versione del DB fino a quando non saranno ritirate.

  • Duplica il codice in modo che ogni versione sia gestita nella stessa applicazione e abbia un percorso di codice completamente separato, ma ciò significherebbe un sacco di duplicazione

  • Riusare un sacco di codice attraverso le versioni, ma ciò renderebbe più difficile mantenere la modifica poiché una versione ha maggiori probabilità di influire su una versione precedente

C'è qualche buona pratica per affrontare questo problema poiché tutte le opzioni sembrano avere i loro problemi?

    
posta Andy Davies 11.03.2014 - 22:45
fonte

3 risposte

5

Fai questo:

Re-use a lot of code across the versions, but this would make it harder to maintain as changing one version is more likely to impact a previous version

ma non rompere le versioni precedenti.

Dovresti avere test che verificano che tutte le versioni supportate funzionino correttamente. Se non hai quei test, dovresti prima crearli per coprire qualsiasi codice che stai modificando.

    
risposta data 11.03.2014 - 23:43
fonte
2

Una combinazione di utilizzo di rami di rilascio GIT (o fork di ciascuna 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 di comuni, è la maggior parte probabilmente la strada da percorrere. Quindi ogni versione dell'API sarebbe un artefatto distaccabile separatamente. Ciò consente flessibilità in modo che, ad esempio, l'API V1 possa dipendere dal comune V1, mentre le API V2, V3, V4 possono dipendere dai comuni V2. Questo sarebbe il più semplice e più pulito dal punto di vista dello sviluppo in quanto il codice base non si moltiplica con ogni nuova versione, ma ogni versione è isolata nel proprio progetto / codice base e riguarda solo se stessa.

Un altro motivo per distribuire artefatti distinti è che potrebbero esserci problemi trasversali come un meccanismo di sicurezza, o framework / librerie come il framework delle dipendenze che potrebbe cambiare nelle versioni più recenti dell'API e creerebbe molte difficoltà nel supportare le vecchie API se tutte vivono nello stesso codice base (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 versioni precedenti delle API potrebbero richiedere un qualche tipo di manutenzione per funzionare con tali modifiche o l'introduzione di alcuni altri strumenti (come le viste del database) per aiutare la compatibilità. Questa potrebbe essere una difficoltà inevitabile a seconda della natura delle tue modifiche.

    
risposta data 08.01.2015 - 19:21
fonte
0

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

Detto questo, di solito non funziona mai uno a uno - quindi un progetto di tipo switch o stato macchina mi ha aiutato con questo problema.

    
risposta data 12.03.2014 - 02:28
fonte

Leggi altre domande sui tag

Modelli per mantenere la coerenza in un sistema distribuito, basato su eventi? Le migliori pratiche durante la forking del codice base