Diciamo che stai cercando di rompere le tue applicazioni in servizi. Ci sono buone ragioni per adottare un approccio SOA rispetto alla semplice creazione di un'API di libreria che può essere caricata dalle applicazioni che ne hanno bisogno.
La differenza potrebbe essere sottile tra entrambi. Ad esempio, nel mondo .NET, potresti avere un'applicazione che si sentirebbe monolitica a un utente finale e che funzionerà su una stessa macchina, ma all'interno, sarebbe separata in un gruppo di servizi WCF. Potresti anche avere architetture in cui le librerie non sono strongmente collegate (addin / plugins) e stanno solo seguendo un protocollo quando parlano tra loro.
Se evitiamo di parlare di questi casi di intermediazione e trattiamo solo con una libreria API strongmente collegata rispetto a un servizio REST separato, ti consigliamo di prendere in considerazione i seguenti punti:
Un'API di libreria viene chiamata sulla stessa macchina. I servizi possono essere ospitati ovunque ed essere richiamati da qualsiasi luogo. Se stai contando l'hosting dell'applicazione su più macchine per motivi di prestazioni / scalabilità / sicurezza, è probabile che dovrai utilizzare i servizi.
La situazione è simile quando si utilizza un servizio da un'applicazione distribuita su più macchine. Ad esempio, se stai facendo un'applicazione per una banca eseguendo alcuni calcoli finanziari, un modo è quello di distribuire l'intera applicazione di grandi dimensioni su tutti i desktop, ed essere costretti a fare aggiornamenti di grandi dimensioni per ogni client ogni volta; un altro approccio sarebbe quello di ospitare la parte di calcolo sui server e distribuire ai desktop solo un'app leggera con solo un'interfaccia utente e un sacco di chiamate a quei server.
Se stai ospitando un servizio REST, chiunque può usarlo: un utente Mac, una persona che usa Linux, ecc. Se hai creato una libreria C # con Visual Studio e la si distribuisce come una DLL , dimentica gli utenti (clienti?) che non hanno Windows.
Un altro vantaggio dei servizi è che quando si aggiorna il servizio, viene immediatamente distribuito a tutti gli utenti del servizio. Quindi, se hai corretto un bug o un problema di prestazioni, tutti ottengono il vantaggio non appena il servizio aggiornato viene pubblicato, invece di dover distribuire un aggiornamento che le persone potrebbero scegliere di ignorare.
Vantaggi della libreria:
Vantaggi del servizio:
Un approccio SOA consente ai vari servizi di essere ospitati e gestiti separatamente. Oltre al codice, la distribuzione di un particolare servizio potrebbe richiedere molte configurazioni speciali (password, porte, certificati, ecc.). Il consumo di un servizio REST ha una quantità limitata di complessità che può essere chiaramente documentata e facilmente comprensibile. È anche più sicuro perché significa che non è necessario concedere l'accesso a DB o altre risorse ai client.
Se viene apportata una modifica a un servizio SOA, tale servizio SOA dovrà essere nuovamente elaborato, ritestato e ridistribuito. Tutte le applicazioni che consumano tale servizio possono continuare a farlo. Una modifica a una libreria in una DLL significherà che tutti i consumatori di tale libreria dovranno essere riscritti per fare riferimento a tale DLL, dovranno essere tutti sottoposti a nuovo test e dovranno essere ridistribuiti tutti. C'è anche il pericolo che questo non avvenga correttamente e diverse applicazioni avranno versioni differenti della DLL. A volte questo potrebbe non essere un problema - forse ogni sistema dovrebbe avere la versione della libreria che era presente al momento della distribuzione (potresti avere aggiornato il tuo sistema di registrazione per avere utili nuove funzionalità - hai veramente bisogno di aggiornare ogni sistema con esso?) in questo caso una libreria va bene. Supponiamo però che tu abbia un servizio per calcolare l'aliquota fiscale e che le leggi fiscali cambino. Non si vuole dover aggiornare ogni sistema per incorporare questo cambiamento, sarebbe meglio farlo in un unico posto. In questo caso, un servizio è un'opzione migliore.
Ci sono molte buone risposte, ma vorrei aggiungere più cose alle risposte date:
Il metodo della libreria API è molto utile quando vuoi interagire con le cose con il minor overhead possibile. La conseguenza è che esiste un accoppiamento più elevato tra API e le applicazioni che lo utilizzano. A volte, questo va bene per l'applicazione e anche necessario, tuttavia se si dispone di un sistema molto distribuito o se si ritiene che l'interoperabilità sia un problema enorme, potrebbe essere necessario fare un passo avanti nell'astrazione e utilizzare altri modi di comunicare. Soprattutto, se vuoi avere un sistema distribuito, SOAP è il prossimo passo in SOA, ma ti rimane la dipendenza tra le unità, poiché devono conoscersi le procedure. REST lo porta ad un nuovo livello, consentendo ad una macchina di imparare qualcosa sul contenuto degli altri servizi in modo unificato.
Nel tuo caso, se la tua applicazione non è distribuita, non vedo alcun motivo per trasformare l'applicazione in SOA.