Ho un'applicazione che è divisa in un numero di servizi. Da una precedente domanda qui, penso che inizialmente JSON / REST sia la via da seguire per la comunicazione.
Alcuni dei miei servizi micro devono essere disponibili pubblicamente, da utilizzare da parte di terze parti.
Quindi ora mi sto interrogando sul modo migliore di strutturarlo. Riesco a vedere 2 diverse strutture, ciascuna con pro e contro.
- Ogni servizio ha il proprio dominio e livello di servizio Web, quindi potrei avere
api.customers.mycompany.com
,api.documents.mycompany.com
,api.users.mycompany.com
ecc. - Tutti i servizi si trovano dietro un livello di servizio Web comune, quindi ho;
api.mycompany.com/customers
,api.mycompany.com/documents
ecc.
L'opzione 1 offre una migliore riduzione delle dipendenze e della manutenibilità, ma al costo di dover gestire molti più domini e, se una terza parte ha bisogno di accedere a diversi servizi, deve archiviare e gestire diversi URL diversi
L'opzione 2 ovviamente rende più difficile la manutenzione e lo sviluppo, poiché l'intero livello Web deve essere aggiornato se viene aggiunto un nuovo metodo a qualsiasi API e il livello Web acquisisce la conoscenza delle chiamate di marshalling per ogni servizio specifico. Ma l'opzione 2 centralizza anche la registrazione, la gestione degli errori del servizio di sicurezza e così via. Significa anche che noi (e le nostre terze parti) abbiamo solo un singolo dominio di cui preoccuparci.
Quindi la mia domanda è; per quelli di voi che sono andati su questa strada, quale opzione avete scelto e ve ne siete pentiti?