Il datore di lavoro mi chiede di utilizzare l'API per l'intero sito web?

Il consumo della propria API è un caso comune. È spesso chiamato Mangiare il tuo cibo per cani se ricordo bene.

Attualmente sto facendo la stessa cosa per un progetto. Ho creato la mia libreria Data Access Layer e non la userò direttamente sul mio progetto web. Invece, creerò le API REST per raggiungere i dati dal mio sito web.

Il modo in cui gestisco l'autenticazione è un altro problema. Quello che farò è darmi un APIKey come darò agli altri e andrò da lì.

Quali vantaggi offre? Bene, gestirò le statistiche sulle API REST e davvero non voglio fare di nuovo lo stesso lavoro. Inoltre, in questo modo, il mio unico problema di accesso ai dati è il mio progetto API.

Non è questo il modo corretto di astrarre un sito così può avere più front-end che visualizzano gli stessi dati, possibilmente in diversi formati? Forse non è un'API in piena regola, ma in .NET è abbastanza comune avere un "livello di servizio web" che si trova in cima al livello DAL e Business, quindi puoi scrivere un front end sottile che si concentra quasi interamente sui problemi di visualizzazione solo da tutto ciò di cui ha bisogno per lavorare viene estratto dal servizio web, e questo ti consente anche di avere vari front-end che puntano tutti allo stesso servizio.

Chiedigli di spiegare come consumerai la sua API. Molto probabilmente, svilupperai una combinazione di pagine sul lato server e Javascript per effettuare chiamate REST sul sito web.

Potresti sviluppare una pagina che chiama l'API quindi incorpora la risposta nella pagina web. Oppure rinuncia a scrivere del codice lato server e fallo con tutti i Javascript (vedi link ).

Sì, se si scrive codice che delega a un'API tramite chiamate HTTP, potrebbe comportare una latenza aggiuntiva, a seconda di quanti hop separano il codice che rende la pagina e il server che implementa l'API. Tuttavia, tale costo deve essere valutato rispetto al codice di duplicazione. Il codice duplicato è due volte più costoso da mantenere.

Questo design non dovrebbe richiedere due back-end separati. Lo scopo dell'utilizzo di una singola API è evitare la duplicazione del codice di back-end.

Rappresenta in modo definitivo l'incomprensione della potenza di un'API. Molte aziende creano più back-end per ciascuna delle loro interfacce interne, le interfacce dei partner.

Identifica i tuoi dati e risorse e implementali come API separate.

Poi consumali attraverso il tuo sistema interno, il tuo partner e il tuo sistema pubblico.

Ho scritto un articolo su questo argomento che fornisce maggiori dettagli.

"If I'm doing front-end, it means there's going to be two back-ends".

No, non è così. Intendi dire che, poiché esiste una separazione tra il front-end e il back-end, ciò implica che ci saranno più frontali o back-end?

La separazione del codice di presentazione (front-end) e della logica è di per sé una cosa buona. Non dovresti mescolare queste due preoccupazioni insieme. Inoltre, se si consente alla logica di essere sul back-end, diversi front-end possono utilizzare lo stesso back-end.

Inoltre è più comune avere diversi front-end per un singolo back-end, quindi il caso che hai menzionato: un singolo front-end con diversi back-end.

Per quanto riguarda il suo approccio alla creazione di un'API per il servizio sia delle versioni standard di web che di quelle mobili, se viene eseguita correttamente, ritengo che questo punto sia vantaggioso.