Nuova versione dell'API REST: distribuire due servizi?

Question

Nuova versione dell'API REST: distribuire due servizi?

#1 da (2 voti)
#2 da (1 voti)

0

Supponiamo di aver bisogno di definire una API REST completamente nuova per un determinato servizio. Queste API di resto si distinguono per qualcosa come "v1" e "v2" nel percorso.

Se sviluppi questi servizi in Java, ti piacerebbe:

Aggiungi i nuovi punti di accesso al progetto specificato e distribuisci una nuova versione che supporta sia i percorsi v1 sia i percorsi v2?
Rimuovere tutti i punti di accesso v1 dal progetto, aggiungere i nuovi punti di accesso v2 e distribuire contemporaneamente due diverse versioni del servizio sul server?

La soluzione 1 ha lo svantaggio che è difficile aggiornare le versioni della libreria perché tutte le modifiche devono essere apportate per entrambe le API. La soluzione 2 ha lo svantaggio di avere due versioni produttive dello stesso servizio che potrebbero confondere. Inoltre, la risoluzione dei bug indica la correzione di due programmi.

java api rest

posta J. Fabian Meier 14.09.2018 - 11:59

fonte

2 risposte

Leggi altre domande sui tag java api rest

I carrelli della spesa dovrebbero essere protetti tramite SSL / TLS Nuove e vecchie tecnologie coesistono nel sistema legacy [chiuso]

score 2 · Answer 1

Sono un grande fan della compatibilità con le versioni precedenti e gestisco la fine della vita di un servizio come un problema di prima classe, quindi

Di preferenza: se è possibile estendere l'interfaccia senza rompere i client esistenti, vai avanti e fallo.
Se non è possibile, distribuisci un nuovo servizio con la nuova interfaccia e termina il vecchio servizio.

If you want to break with the past, use a different hostname, with new branding! -- Fielding 2013

Quindi la fine della vita qui significa davvero qualcosa come la pubblicità che il servizio precedente è stato deprecato e che comunica ai consumatori quando termina il supporto per il nuovo servizio.

A volte penso al contratto tra servizio e consumatori come una sottoscrizione - quando i consumatori si iscrivono, viene loro data la promessa che il servizio continuerà ad essere disponibile fino a qualche punto fisso in futuro e la comprensione che possono rinnovare l'abbonamento.

(L'abbonamento non è un ottimo termine, perché qui non stiamo parlando di fatturazione, ma è una garanzia che il servizio sarà disponibile fino a almeno $ DATE).

Potrebbe essere utile rivedere Pieter Hintjens: La fine delle versioni del software .

The first step to enlightenment is to see that contracts have a life-cycle. This applies to all contracts, both in software and in the real world. The contract life-cycle is not an invention, it's a feature of real world economics, and a useful one for software engineering.

score 1 · Answer 2

Dovresti implementare un server che supporti BOTH v1 e v2, per dare tempo ai client di migrare il loro utilizzo dell'API.

Quante versioni precedenti supportate e per quanto tempo è una funzione delle vostre pratiche aziendali, quanto velocemente passate da una versione all'altra, quanto velocemente si passano i client (software client) e i costi di rottura del software client a causa della versione skew (un client che conta su v1 si rompe perché non si è liberato del supporto per v1).

Una buona regola empirica della mia esperienza (forse dice di più sulle attività in cui ho lavorato - potrebbe non applicarsi alla tua) - è mantenere la compatibilità con le versioni precedenti per un anno o due.

Nota anche - Riscrivo sempre la mia implementazione API per v1 (una volta che ho la v2 disponibile) semplicemente per INDIRECT / CALL dell'API v2. Ciò riduce la duplicazione del codice e rende più chiare le differenze tra le versioni delle API.

Spero che questo aiuti.