Perché usare i servizi (REST / SOAP) invece di una libreria?

Diciamo che stai cercando di suddividere le tue applicazioni in servizi. Ci sono buoni motivi per adottare un approccio SOA piuttosto che creare un'API di libreria che può essere caricata dalle applicazioni che ne hanno bisogno.

La differenza può essere sottile tra entrambi. Ad esempio nel mondo .NET, potresti avere un'applicazione che sembrerebbe monolitica per un utente finale e che funzionerà su una stessa macchina, ma al suo interno sarebbe separata in un gruppo di servizi WCF. Potresti anche avere architetture in cui le librerie non sono fortemente collegate (componenti aggiuntivi / plug-in) e stanno solo seguendo un protocollo quando parlano tra loro.

Se evitiamo di parlare di quei casi intermedi e trattiamo solo una libreria API fortemente collegata rispetto a un servizio REST separato, allora potresti voler considerare i seguenti punti:

1. Un'API della libreria viene chiamata sullo stesso computer. I servizi possono essere ospitati ovunque ed essere chiamati da qualsiasi luogo. Se stai contando di ospitare l'applicazione su più macchine per motivi di prestazioni / scalabilità / sicurezza, è probabile che dovrai utilizzare i servizi.

2. 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 che esegue alcuni calcoli finanziari, un modo è distribuire l'intera applicazione di grandi dimensioni su ogni desktop ed essere costretto a fare aggiornamenti di grandi dimensioni su ogni client ogni volta; un altro approccio sarebbe quello di ospitare una parte di calcolo sui server e distribuire ai desktop solo un'app leggera con solo un'interfaccia utente e un sacco di chiamate a tali server.

3. Se stai ospitando un servizio REST, chiunque può usarlo: un utente Mac, una persona che utilizza Linux, ecc. Se hai creato una libreria C # con Visual Studio e lo distribuisci come DLL, dimentica gli utenti (clienti ?) chi non ha Windows.

Un altro vantaggio dei servizi è che quando si aggiorna il servizio, questo viene immediatamente distribuito a tutti i consumatori del servizio. Quindi, se hai risolto un bug o un problema di prestazioni, tutti ne traggono vantaggio non appena il servizio aggiornato diventa attivo, invece di dover distribuire un aggiornamento che le persone potrebbero scegliere di ignorare.

Vantaggi della biblioteca:

• Un overhead per chiamata inferiore (solo salto o persino inline ) = può aumentare le prestazioni
• La cosa più semplice che potrebbe funzionare
• Nessun rischio di interruzione del servizio centralizzato e impatto su tutti i consumatori

Vantaggi del servizio:

• Tutti ricevono gli aggiornamenti immediatamente e in modo trasparente (a meno che non sia offerto l'API con versione)
• I consumatori non possono decompilare il codice
• Può ridimensionare l'hardware di servizio separatamente
• Tecnologia agnostica. Con una biblioteca condivisa, i consumatori devono utilizzare una tecnologia compatibile.
• Più sicuro. Il livello UI può chiamare il servizio che si trova dietro un firewall invece di accedere direttamente al DB.

Un approccio SOA consente di ospitare e gestire separatamente i vari servizi. Oltre al codice, la distribuzione di un particolare servizio può 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 ai DB o ad altre risorse ai client.

Se viene apportata una modifica a un servizio SOA, tale servizio SOA dovrà essere riqualificato, ritestato e ridistribuito. Tutte le applicazioni che utilizzano tale servizio possono continuare a farlo. Una modifica a una libreria in una DLL significherà che tutti i consumatori di quella libreria dovranno essere riqualificati per fare riferimento a quella DLL, dovranno essere tutti testati nuovamente e dovranno essere tutti ridistribuiti. Esiste anche il pericolo che ciò non accada correttamente e diverse applicazioni avranno versioni diverse 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 aver aggiornato il tuo sistema di registrazione per avere utili nuove funzionalità - hai davveroè necessario aggiornare ogni sistema con esso?) in questo caso una libreria va bene. Supponiamo che tu abbia un servizio per il calcolo dell'aliquota fiscale e che le leggi fiscali cambino. Non è necessario aggiornare tutti i sistemi per incorporare questa modifica, sarebbe meglio farlo in un unico posto. In questo caso un servizio è un'opzione migliore.

Esistono diverse risposte valide, ma vorrei aggiungere più elementi alle risposte fornite:

Il metodo della libreria API è molto utile quando si desidera interagire con le cose con il minor sovraccarico possibile. La conseguenza è che esiste un accoppiamento più elevato tra l'API e le applicazioni che la utilizzano. A volte, questo va bene per l'applicazione e persino necessario, tuttavia se hai un sistema molto distribuito o pensi che l'interoperabilità sia un problema enorme, potresti dover fare un passo avanti nell'astrazione e usare altri modi di comunicare. Soprattutto, se si desidera disporre di un sistema distribuito, SOAP è una specie del passo successivo in SOA, ma si rimarrà comunque con la dipendenza tra le unità, poiché devono conoscere le reciproche procedure. REST lo porta a un nuovo livello, consentendo a una macchina di apprendere qualcosa sui contenuti degli altri servizi in modo unificato.

Nel tuo caso, se la tua applicazione non è distribuita, non vedo alcun motivo per trasformarla in SOA.