Stavo controllando il servizio app su Azure e in one of the tutorial vengono create due app per le API, una per i dati e una per le app esterne.
Non mi è chiaro dal tutorial quale sia il vero vantaggio di avere questa separazione. Poiché suppongo che tutta l'API di dati sia destinata a fare riferimento a un database, perché non collegare semplicemente il DB direttamente all'app delle API che verranno utilizzate dalle app esterne? Qualcuno può dirmi cosa mi manca qui?
Si chiama separazione delle preoccupazioni . L'esempio prende il principio oltre l'ambito delle classi e degli oggetti.
Una vaga descrizione dei componenti potrebbe essere:
L'API dati è destinata a essere ciò che conosciamo come DAO.
L'app per le API è il luogo in cui il modello di dominio e l'azienda vengono eseguite (o parte di esse) ed è esposta tramite Web API. Questo tipo di app potrebbe integrare più servizi. Ecco perché sono conosciuti come middleware .
L'esempio fornito illustra il tipo di architettura che si prevede venga distribuito nel cloud. Microservizi .
Forse, l'esempio è troppo semplice e entrambi i componenti (API) sembrano fare la stessa cosa, ma le differenze si trovano nelle rispettive responsabilità (come parte di un intero).
why not just connect the DB directly to the API app your external apps are going to be using?
Potresti davvero. Tocca a voi. Sono le tue esigenze, le tue esigenze, il tuo design. Nel caso dell'esempio non importa. Il sistema è molto semplice.
Tuttavia, in sistemi più complessi, potresti subire ciò che conosciamo come accoppiamento . Non quello tra le classi. Quello tra app / servizi.
L'esempio sta cercando di essere il più semplice, completo e adatto al contesto (cloud) possibile.
Leggi altre domande sui tag api-design architecture azure