Condividi tramite

Creazione, evoluzione e controllo delle versioni di API e contratti di microservizio

Suggerimento

Questo contenuto è un estratto dell'eBook, Architettura di microservizi .NET per applicazioni .NET containerizzati, disponibile in documentazione .NET o come PDF scaricabile gratuitamente leggibile offline.

Scaricare il PDF

Architettura di Microservizi .NET per Applicazioni .NET Containerizzate miniatura della copertina dell'eBook.

Un'API di microservizio è un contratto tra il servizio e i relativi client. Sarà possibile evolvere un microservizio in modo indipendente solo se non si interrompe il contratto API, motivo per cui il contratto è così importante. Se si modifica il contratto, influisce sulle applicazioni client o sul gateway API.

La natura della definizione dell'API dipende dal protocollo in uso. Ad esempio, se si usa la messaggistica, ad esempio AMQP, l'API è costituita dai tipi di messaggio. Se si usano servizi HTTP e RESTful, l'API è costituita dagli URL e dai formati JSON di richiesta e risposta.

Comunque, anche se si considera attentamente il contratto iniziale, un'API di servizio dovrà cambiare nel tempo. In questo caso, e soprattutto se l'API è un'API pubblica usata da più applicazioni client, in genere non è possibile forzare l'aggiornamento di tutti i client al nuovo contratto API. In genere è necessario distribuire in modo incrementale nuove versioni di un servizio in modo che entrambe le versioni precedenti e nuove di un contratto di servizio vengano eseguite contemporaneamente. È quindi importante avere una strategia per il controllo delle versioni del servizio.

Quando le modifiche all'API sono di piccole dimensioni, ad esempio se si aggiungono attributi o parametri all'API, i client che usano un'API precedente devono passare e usare la nuova versione del servizio. Potrebbe essere possibile fornire valori predefiniti per gli attributi mancanti necessari e i client potrebbero essere in grado di ignorare eventuali attributi di risposta aggiuntivi.

Tuttavia, a volte è necessario apportare modifiche importanti e incompatibili a un'API del servizio. Poiché potrebbe non essere possibile forzare l'aggiornamento immediato delle applicazioni client o dei servizi alla nuova versione, un servizio deve supportare le versioni precedenti dell'API per un certo periodo. Se si usa un meccanismo basato su HTTP, ad esempio REST, un approccio consiste nell'incorporare il numero di versione dell'API nell'URL o in un'intestazione HTTP. È quindi possibile decidere tra l'implementazione simultanea di entrambe le versioni del servizio all'interno della stessa istanza del servizio o la distribuzione di istanze diverse che gestiscono una versione dell'API. Un buon approccio per questa funzionalità è il modello Mediator (ad esempio, la libreria MediatR) per disaccoppiare le diverse versioni di implementazione in gestori indipendenti.

Infine, se si usa un'architettura REST, Hypermedia è la soluzione migliore per il controllo delle versioni dei servizi e per consentire API evocabili.

Risorse aggiuntive

PrecedenteAvanti