Proprio dalla domanda, non è possibile individuare un singolo pattern perché ci sono più aspetti di un pattern. A seconda di come il tuo servizio è architettato , lo schema può variare. In generale, tuttavia, ciò che hai specificato è l' Astrazione di servizio principio di progettazione .
Inoltre, molto spesso un software, specialmente nell'ambito di un servizio web, è composto da più modelli di progettazione. Quindi un servizio web può essere progettato con pattern Model-View-Controller mentre ha un set di adattatori, mappatori di dati, (spiegato sotto) ecc. Nei suoi vari livelli. È ancora possibile identificare il suo valore aziendale primario e mapparlo in base a un modello di progettazione, se ciò è importante per il progetto. Quindi, anche se non tutti gli schemi di cui parlo di seguito possono essere considerati modelli di progettazione enterprise da tutti, trovo più utile usare il modello che trasmette ciò che fa il servizio più che se sia necessariamente un modello di progettazione aziendale o no.
Da quanto hai affermato nella tua domanda, sembra molto probabile che sia Façade o la sua specializzazione Remote Façade . Sarebbe una facciata se il suo scopo principale fosse di semplificare l'API sottostante e nascondere la complessità (che è ciò che stai affermando). Inoltre, Remote Façade punta a ridurre il numero di chiamate tra due sistemi, se questo è un problema.
Un pattern Adapter viene solitamente architettato con l'assunto che ci saranno più adattatori (sia presente che futuro). Pertanto, se la tua preoccupazione principale è creare un servizio web in modo tale da fornire un'interfaccia coerente ed essere in grado di eseguire varie operazioni sui servizi sottostanti, allora stai progettando un adattatore. Un tipico esempio potrebbe essere quando offri un nuovo servizio di distribuzione ed esporti un metodo chiamato Compile() . Implementa due adattatori, uno per MSBuild e l'altro per nmake. A seconda del sistema in cui è scritto un particolare progetto, verrà prelevato l'adattatore corretto ed emesso i comandi appropriati.
Un modello simile è Mapper dei dati che sta mappando un insieme coerente di dati digita tipi di dati di vari archivi di dati sottostanti. Diciamo che se il tuo servizio esponeva un campo UserId al suo client in modo tale che mappasse su un UserName e un UserPrincipal in due archivi di dati diversi, allora questo è ciò che stai guardando. Ciò non significa necessariamente disporre di più archivi di dati, significa che stai architettando pensando a questa possibilità.
Il pattern Bridge viene solitamente applicato laddove esiste un'astrazione e la sua implementazione, e tuttavia entrambi devono essere variati. In genere, l'implementazione viene realizzata utilizzando un modello di adattatore, quindi ti ritroverai con l'astrazione e le sue sottoclassi, oltre a un set di adattatori.
Un gateway è più adatto a fornire un'interfaccia coerente tra i servizi. Quindi potresti avere un www.myservice.com che espone una API REST, che a sua volta chiama altri servizi che potrebbero utilizzare vari protocolli. È responsabilità del Gateway garantire che i client ottengano sempre la stessa interfaccia, anche quando uno qualsiasi di questi servizi decide di cambiare i suoi protocolli.