API REST di applicazioni Web: i dati devono essere strutturati in modo da soddisfare i requisiti dell'interfaccia utente sul client o sul server?

Il tuo approccio dipenderà dal fatto che l'app web sia l'unico utente dell'applicazione di back-end o meno. Può anche dipendere da ciò che il tuo team di sviluppo (in questo caso tu stesso) è più abile in: sviluppo backend o frontend.

La mia preferenza è avere la maggior logica possibile nell'app backend e il meno possibile nel frontend. Ciò è dovuto sia al mio skillset sia alla mia convinzione che la logica di business sia più facile da implementare e testare nel backend (che può essere di parte, ovviamente).

Quindi quello che farei sarebbe:

• Se il tuo frontend è l'unico utente dell'app di back-end, allinea tutte le API in modo che siano facili da utilizzare nell'interfaccia utente e fornisci i dati come strettamente correlati a ciò che l'interfaccia utente presenta come possibile. In questo modo la tua logica è quasi tutta nel backend (più facile da sviluppare e testare l'IMO) e il frontend può concentrarsi solo sulla presentazione dei dati senza occuparsi di molta logica aziendale.
• Se la tua app di back-end ha altri utenti oltre al frontend, o devi comunicare con un'app backend scritta da qualcuno elase dove hai un controllo limitato sull'API, prenderei in considerazione la scrittura di un Backend-for-Frontend (BfF) . Un Backend-for-Frontend è un'app di back-end che funge da proxy tra l'interfaccia utente e il "vero back-end". In questa app puoi trasformare i dati dal formato del backend in un formato pronto per essere utilizzato dall'interfaccia utente. Puoi quindi avere un'app di frontend molto semplice e tutta la logica di business nel BfF. Essenzialmente, il BfF è una facciata che ti consente di utilizzare l'approccio descritto nel precedente punto elenco quando non puoi modificare direttamente l'API dell'app backend in modo che corrisponda all'interfaccia utente.

Dipende davvero dal tuo pubblico di destinazione per l'API. Se intendi pubblicare un'API pubblica, devi davvero progettare in tal senso. Se l'API è rigorosamente per supportare l'interfaccia utente, allora lascia che sia costruita ad hoc.

Tuttavia, questo è uno degli usi per GraphQL e Falcor (o altri simili). GraphQL ha una curva di apprendimento più alta, ma ti consente di mappare le richieste per i dati precisi che devi mostrare attraverso i servizi web. La tua API pubblica rimane invariata e hai questo linguaggio di query unificato per consolidare le richieste di dati in una sola. Poiché GraphQL di solito vive in un proxy API di ordinamento, consente una memorizzazione intelligente nella cache.

Viene fornito con una curva di apprendimento elevata, ma ottieni molto potere per il tuo investimento. Pesare i costi in base alle proprie esigenze. Se la tua API è abbastanza semplice, puoi rimandare a questo aspetto finché le tue esigenze non diventeranno davvero complesse.

Nel caso in cui lo scopo principale dell'API sia quello di spingere i dati in una singola app Web, ritengo che la sua struttura accettabile sia adatta (ma non tutti) i metodi dell'API a essere adattati all'app Web. Assicurati di avere alcuni endpoint API generali che possono essere utilizzati per scopi più generici in seguito, se tali requisiti vengono visualizzati rapidamente.

Penso che a volte ci diamo più lavoro del necessario per gli strati decrescenti nelle nostre applicazioni necessariamente, o rigorosamente

Non sono sicuro che questa breve risposta ti possa aiutare. Normalmente non strutturo i dati secondo l'interfaccia utente del client e mi assicuro di inviare abbastanza informazioni al client e lasciare che il client crei il modello appositamente per soddisfare i requisiti dell'interfaccia utente. Questo mi aiuta a mantenere la preoccupazione lato client separata dal server. Anche perché il server dovrebbe pensare anche se il consumatore di api è un'applicazione web, un'applicazione mobile o anche un'applicazione wpf basata su desktop.