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

3

Per un'app Web su cui sto lavorando ho un database relazionale piuttosto semplice. Accedo a questo database tramite un'API RESTful e genera il markup in React una volta recuperati i dati.

Se mi trovo costantemente a manipolare / elaborare queste risposte JSON sul lato client solo per strutturare questi oggetti in strutture più amichevoli per la mia interfaccia utente, è un segnale che forse sto facendo troppo sul client?

Sono relativamente nuovo nel settore per cominciare e sono più interessato a sapere quando dovrei portare queste cose a un altro sviluppatore che forse sta lavorando al back-end in questione.

Questo può sfociare in una più ampia domanda sulle API REST per le app Web in generale:

Dovrei aspettarmi che le risposte ai miei recuperi di dati sul front-end siano già strutturate in base ai requisiti dell'interfaccia utente o chiederei troppo?

Un buon esempio di questo sarebbe un elenco di categorie per una pagina "Prodotti". È ragionevole che io recuperi l'elenco totale di prodotti e poi crei l'elenco di categorie da quei dati o dovrei aspettarmi di avere un elenco già strutturato delle categorie, ecc. Nell'oggetto risposta quando inizialmente ho deciso di recuperare il elenco di prodotti?

    
posta connected_user 12.03.2018 - 13:26
fonte

4 risposte

2

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.
risposta data 12.03.2018 - 19:55
fonte
3

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.

    
risposta data 12.03.2018 - 21:06
fonte
1

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

    
risposta data 12.03.2018 - 15:56
fonte
0

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.

    
risposta data 12.03.2018 - 14:18
fonte

Leggi altre domande sui tag