Utilizziamo C # MVC e Angularjs come strumenti principali per sviluppare le nostre applicazioni web. Recentemente abbiamo discusso delle migliori pratiche, con un occhio rivolto alla revisione dei nostri approcci di sviluppo in qualcosa di un po 'più strutturato.
Uno degli argomenti riguarda il modo in cui gestiamo le API.
Più in particolare, stiamo cercando di utilizzare le API Web come mezzo per comunicare dai controller AngularJS lato client e dai controller C # lato server. I dati di base del modello sarebbero passati dal controller C # attraverso la vista nel DOM, ma gli elementi dinamici verrebbero caricati tramite le chiamate Ajax alle API Web.
Ciò ha portato alla domanda: come organizziamo le nostre API?
I nostri modelli di dati per queste API sembrano generalmente rientrare in una delle due categorie: modelli complessi che rappresentano le gerarchie degli oggetti dati e modelli semplici per il popolamento dinamico della vista (come il caricamento di ng-options per select tag).
Non stiamo pianificando di andare completamente RESTful, a meno che il progetto specifico identifichi che le API saranno esposte a entità di terze parti, poiché la corretta configurazione di HATEOAS sembra eccessivo per API intese come puramente interne.
Un'alternativa all'utilizzo di API di oggetti dati complessi e API molto semplici sarebbe utilizzare solo oggetti di dati complessi e includere in tali oggetti ogni elenco dipendente che potrebbe essere necessario all'interno della vista. La mia preoccupazione principale per questo approccio è che alcuni di questi modelli complessi potrebbero diventare molto grandi, il che potrebbe avere un impatto significativo sulle prestazioni. Naturalmente, una tonnellata di piccole chiamate API potrebbe anche influire sulle prestazioni.
A titolo di esempio, uno degli oggetti in un progetto corrente è un tipo di documento che può avere una o più attività ad esso associate (e ogni attività è associata a un singolo documento principale).
All'interno del modulo associato a quel documento, ha senso il caricamento di tutte le attività ad esso associate come parte della principale chiamata API. Tuttavia, tale oggetto documento viene fatto riferimento in altre posizioni all'interno dell'applicazione in cui vogliamo che gli utenti scelgano un'istanza di quel tipo di documento, a quel punto un secondo elenco a discesa viene popolato con tutte le attività associate a quel documento.
Avere una pagina che carica centinaia o migliaia di questi documenti, inclusi fino a una mezza dozzina di compiti per ciascuno di questi documenti, sembra essere un successo maggiore rispetto a una singola chiamata per recuperare l'ID e la descrizione di ogni documento, e quindi con un secondo trigger API sulla selezione, che caricherà l'elenco a discesa delle attività con solo le attività associate a quel documento.
Questa strategia di combinazione di API modello complesse e API semplici è una buona idea? Quali sono le principali insidie a cui prestare attenzione? C'è un'architettura migliore da impiegare?