Abbiamo un'applicazione ASP.NET MVC che si trova sopra un database MySQL. Ora stiamo pensando di creare un'API REST pubblica in modo che terze parti possano integrare i loro servizi con i nostri.
Ora preferirei che l'applicazione API non acceda direttamente allo stesso database. Mi piace l'idea di un'applicazione che "possiede" i propri dati. Apportare un cambiamento interno al modello di dati dell'app Web influirebbe inevitabilmente anche sull'API pubblica:
Tuttavia,l'unicaalternativachepossopensaresarebbequelladiimpostareunbusdeimessaggiefarsìcheledueapplicazionicomunichinoattraversoquesto.Quindi,quandounclientesternorichiedeunaporzionedidatidallanostraAPIpubblica,l'APIcreeràquindiunmessaggiosulbusdiserviziochevienepoigestitodall'appWeb,chequindirispondeconidatidesiderati.Seandiamoconquestodesign,l'applicazionewebsarebbel'unicaapplicazionecheaccedealdatabase.Epotremmousarediversimodellidiscambiodiinformazionisulbusdiservizio,comerichiesta/rispostacomeinquestoesempio,opub-subpercosecome"qualcosa è successo".
Ora, per assicurarmi che i tipi di messaggi siano coerenti in entrambe le applicazioni, stavo pensando di inserirli in un assembly separato e di farli utilizzare dalle due applicazioni come pacchetto Nuget. Tuttavia, questo ci porterebbe di nuovo al punto di partenza, perché ora entrambe le applicazioni sono strettamente collegate a questo modello di oggetti condiviso. E anche se usassimo pratiche come il controllo delle versioni semantiche, temo che sarà una fonte di grande frustrazione e un sacco di lavoro extra.
Qualche commento su questo? Forse esiste un'architettura completamente diversa che si adatta meglio alle nostre esigenze?
Modifica
Devo sottolineare che il bus di servizio di cui sto parlando non sarebbe un ESB, ma piuttosto una semplice coda di messaggi.
Devo dire che sono piuttosto perplesso dalla mancanza di articoli e post di blog su questo argomento. Sembra che oggigiorno ogni SaaS là fuori abbia un'API rivolta verso l'esterno, quindi ora dovrebbero esserci alcune buone pratiche.