Versioning delle API HTTP e necessità di introdurre modifiche di rottura a tutte le versioni supportate

Naviga le tue risposte
2

Sto sviluppando un'applicazione HTTP e la distribuisco eseguendo il versioning contro versioning semantico modelli / tecniche / qualunque essi siano. Per non rompere i client esistenti e consentire alle versioni di essere flessibili, esistono diverse regole per le versioni:

  • Allo stesso tempo, supporta due versioni principali. Per esempio. 2.3.4 e 3.4.5 possono essere entrambi supportati contemporaneamente, ma per esempio non ci sarà il supporto per 2.3.4, 3.4.5, 4.5.6.
  • È possibile applicare una correzione rapida alla versione inferiore supportata dell'applicazione HTTP. Ad esempio, ho due versioni dell'applicazione HTTP in esecuzione: 2.3.4 e 3.4.5. Applicherò una hot-fix sulla versione 2.3.4 e eseguirò il bump della sua versione in 2.3.5.

Questo scenario copre principalmente tutti i miei bisogni, tranne per il caso in cui ho bisogno di applicare una modifica ad entrambe le versioni allo stesso tempo e che il cambiamento introduca un cambiamento sostanziale. Ad esempio, considera il seguente scenario:

Le versioni 2.3.4 e 3.4.5 dell'applicazione sono in esecuzione. Abbiamo scoperto un bug di sicurezza e sistemato quel bug introdurrebbe una modifica sostanziale a due delle versioni implementate. Nello scenario ideale, sarei la versione della nuova versione come 4.0.0 e andrò in pensione la versione 2.3.4. Quindi, 4.0.0 e 3.4.5 saranno le versioni supportate, ma in questo caso, 3.4.5 deve essere ritirato e ha un buco di sicurezza.

Come descriveresti questo caso o come lo gestisci oggi se hai un'applicazione e una struttura di distribuzione simili? Non ci siamo ancora imbattuti in uno scenario come questo, ma non voglio continuare la mia vita con un punto interrogativo come questo:)

Aggiornamento:

Why are you originally supporting two different builds?

Diversi motivi:

  1. Questo servizio HTTP supporta più di un client (diciamo migliaia). Quindi, non è possibile aggiornarli contemporaneamente. Ragioni classiche per cui desideri eseguire la tua versione.

  2. Supponiamo che solo io sia un utente di questo servizio HTTP. Anche con quello, non è possibile per me aggiornare i miei client e l'applicazione HTTP contemporaneamente. Quindi, ho ancora bisogno del controllo delle versioni. Se questo fosse il caso, lo scenario di cui sopra sarebbe meno problematico visto che sto controllando tutti i client.

posta tugberk 19.05.2015 - 23:17
fonte

1 risposta

2

Penso che per rispondere a questa domanda, è necessario porsi un'altra domanda più importante ...

Perché stai originariamente supportando due diverse build?

Molto probabilmente la risposta sarebbe perché hai clienti che hanno un tempo diverso nell'introdurre nuove versioni principali, il che ha perfettamente senso. Quindi un cliente è su 2.3.4 e non è ancora passato alla 3.4.5 a causa di operazioni, test, ecc. Qualunque sia la ragione, è più lento da adottare. Forse questo cliente implementa ogni altra versione principale.

Ma nel caso dell'aggiornamento rapido causa l'assoluta necessità di un cambio di rottura in entrambe le versioni correnti (a condizione che il cambio di rottura sia deve ). In questo caso, avrebbe senso solo incrementare la tua major della build, e avere una singola build che andasse avanti fino a quando una release principale secondaria diventasse in supporto (per poi continuare a seguire il tuo modello di due build supportati per supportability).

La ragione per cui dico questo è perché il beneficio del supporto di una versione maggiore più vecchia per i clienti non è più lì, poiché li stai costringendo ad adottare modifiche irrisolte in una nuova versione principale.

Quindi, a mio parere, questo sarebbe un buon motivo per avere un punto di convergenza su una singola build supportata fino a quando la tua prossima naturale evoluzione di un'altra major release si verificherà, nel qual caso avresti di nuovo le tue due build supportate.

Dopo le modifiche apportate, avresti la versione 4.0.0 come unica build supportata. E alla fine avresti la tua build 5.x.x, nel qual caso ora supporterai both 4.x.x e 5.x.x.

    
risposta data 19.05.2015 - 23:35
fonte

Leggi altre domande sui tag

Sistema di plug-in dell'applicazione - interfacce - aggiunta di nuove funzionalità Esiste un simbolo valido per "due o più" con la notazione di Crow's Foot?