Disposizione del servizio Web basato su REST

Anche se dici che non è quello che ti serve. La tua domanda suggerisce di non creare un servizio web, ma di utilizzare un proxy inverso sul loro webservice. Qualsiasi accesso passerà attraverso il tuo proxy inverso che potresti reindirizzare a piacimento.

In alternativa puoi fare un po 'di base per le loro risposte, avvolgere il loro XML o JSON nel tuo. Non avresti bisogno di guardare l'XML o il JSON o essere influenzato dalle modifiche nel suo schema.

D'altra parte, se dovessi passare a un altro servizio partner. Pensi che i loro dati sembreranno esattamente gli stessi? I tuoi clienti sarebbero in grado di lavorarci senza modifiche?

Potresti utilizzare il servizio 'wrapper' come facciata per assicurarti che i dati forniti siano conformi alla struttura definita. In una configurazione del genere non si dovrebbe automaticamente passare attraverso qualsiasi campo possa aggiungere un partner. Il tuo webservice renderebbe un partner webservice conforme a un determinato contratto. Protegge fondamentalmente i programmi client da modifiche impreviste.

Ovviamente potresti aggiungere un po 'di tasche di coppie chiave-valore qua e là se ha senso (i dati sono dinamici). Non è necessario un linguaggio di programmazione dinamico per questo.

Ho creato un rest service service wrapper o due.

Non dovresti davvero preoccuparti dei campi di aggiunta dei partner - la serializzazione si muoverà oltre con facilità nella maggior parte dei casi. Bene, a meno che non ti spari al piede e inizi a utilizzare la convalida dello schema sui rendimenti del tuo partner. La rimozione dei campi non causerà un arresto anomalo al momento dell'importazione nella maggior parte dei casi, ma può causare alcuni effetti interessanti lungo la linea. L'unico problema di arresto anomalo è se il tuo partner inizia a cambiare tipo su di te, ad esempio decidere che un identificatore è in realtà una stringa e non un intero. Detto questo, è abbastanza ben compreso come utilizzare le API di versione nel 2012. A meno che non si sia facebook, non si cambiano casualmente le cose sul proprio partner. Se il blob storage è uno dei 3 candidati probabili, mi aspetterei che l'API sia quasi scolpita nella pietra: ci sono abbastanza clienti in libertà per quelli che non potrebbero cambiare senza rovinare qualche milione di giorni da hipsters.

Detto questo, come vorrei creare un sistema di allerta precoce per questo tipo di scenari sarebbe quello di scrivere la mia libreria di wrapper in modo test-driven, assicurandomi di coprire le parti di deserializzazione molto bene e con dettagli a grana fine. Quindi utilizzare un server CI per eseguire automaticamente i test di servizio su detta libreria ogni altra ora circa. Se i test sono buoni, avrai una buona idea di cosa è cambiato, quando e come fa male e forse come risolvere.

Ma davvero non mi preoccuperei di questo troppo dato una buona strumentazione e una gestione degli errori nel tuo prodotto.