Ha senso che il frontend del mio sito Web condivida l'API come terze parti

Se la tua app web è l'unico programma che accede a quell'API, le modifiche API non devono necessariamente essere retrocompatibili, dal momento che aggiornerai immediatamente la tua app a una sola pagina.

Ma non appena pubblichi un'API nel mondo, devi avere cura della retrocompatibilità, altrimenti gli altri sviluppatori che scrivono programmi che consumano la tua API diventeranno molto infelici se i loro programmi smettono di funzionare con ogni nuova versione della tua API .

Quindi o segui la strada descritta da @RobertHarvey nella sua eccellente risposta, oppure rendi alcune parti stabili dell'API pubblica e mantieni le altre parti interne.

Sebbene sia possibile scrivere una singola API che serva sia i client esterni che i client web / desktop, si otterranno miglior adattamento, forma e funzionalità creando API separate.

La ragione di ciò dovrebbe essere evidente: i casi d'uso per i tuoi clienti pubblici saranno quasi certamente diversi da quelli del tuo frontend. Ad esempio, potresti avere un elenco a discesa o comprimibile su uno dei tuoi moduli popolato da un endpoint API specifico, un'operazione a cui i tuoi clienti potrebbero non avere il minimo interesse. Oppure, potresti semplicemente avere funzionalità nel tuo frontend che non non voglio esporlo direttamente nella tua API pubblica.

Ovviamente, nulla impedisce a nessuno di invertire la progettazione della tua pagina web per determinare come funziona l'API non pubblicata. Ecco dove mettere in sicurezza il tuo sito / API entra in gioco. Molte API di frontend espongono semplicemente un'interfaccia REST, un'astrazione CRUD che richiede una conoscenza approfondita dell'architettura del database da utilizzare correttamente. Potresti desiderare che l'API approvata pubblicamente sia un po 'più sfumata di quella.

Quindi, per tutti questi motivi, devi decidere se progettare o meno una singola API o (più probabilmente) due separate e se debbano o meno essere protette.