Esistono pratiche consolidate sul controllo delle versioni di un servizio web condiviso?

Question

Esistono pratiche consolidate sul controllo delle versioni di un servizio web condiviso?

#1 da (2 voti)

6

Stiamo lavorando su un servizio Web XML basato su ASP.NET che utilizzeremo per i nostri scopi e utilizzandolo come parte di un'offerta di prodotti per i nostri partner di integrazione.

Una volta avviato, lavoreremo sulle fasi future del progetto e mi viene in mente che i dettagli del servizio potrebbero dover cambiare nel tempo (firme del metodo, tipi di oggetto, ecc.) e poiché non siamo gli unici quelli che utilizzano il servizio web, avremo bisogno di avere un certo livello di coordinamento con i nostri partner.

Ciò di cui non sono sicuro è il modo migliore per farlo. Quando aggiorniamo il servizio Web in modo tale da modificare il WSDL, dovremmo distribuirlo su un URL separato? Dovremmo sovraccaricare i metodi esistenti? Hanno metodi con nomi diversi? Idealmente avremmo semplicemente coordinato tutto e tagliato ai nuovi metodi, ma non vedo che ciò accada.

Esistono validi modi per gestirlo?

versioning asp.net web-services

posta Tom Kidd 09.03.2012 - 23:43

fonte

1 risposta

Leggi altre domande sui tag versioning asp.net web-services

che si impegnano ad aggiungere il numero / numero di ticket di tracciamento dei bug a dati audio e video in RTP

score 2 · Accepted Answer

When we update the web service in such a way that the WSDL would be changed, should we deploy it to a separate URL?

Potresti versionare l'url (es. www.foobar.com/v2/service.svc). Tuttavia, porterebbe a molti siti. Cosa succede quando correggi bug? Continueresti comunque a supportare versioni buggy? Questo è possibile ma non quello che consiglierei.

Should we overload the existing methods? Have differently named methods?

No. In poche versioni potresti finire con un sacco di metodi ridondanti e il tuo codice sarà un incubo da mantenere.

Are there established good ways to handle this?

Suggerirei di avere delle uscite programmate a intervalli prestabiliti (ogni trimestre?). In questo modo i tuoi clienti noteranno la modifica, aggiorneranno il loro WSDL ed eseguiranno alcuni test per verificare che tutto funzioni ancora. È una questione di pochi minuti ogni trimestre, quindi non dovrebbe essere di disturbo. Le uniche modifiche che dovrebbero interrompere le cose sta cambiando la firma dei tuoi contratti o metodi. Aggiungerne di nuovi non dovrebbe interrompere le vecchie funzionalità o addirittura richiedere un aggiornamento di wsdl.

Un'altra cosa che potrebbe essere utile esaminare è l'interfaccia IExtensibleDataObject per consentire il controllo delle versioni nel tuo datacontract ( msdn qui ). Dai un'occhiata e vedi se è appropriato nel tuo caso.