App per le singole pagine e API di back-end

0

Durante la creazione di app a una sola pagina che comunicano con un'API back-end tramite ajax, qual è la prassi comune (migliore?) in merito all'aggiornamento di diversi oggetti del database lato server come risultato di un'azione lato client? Ad esempio, supponiamo che elimini qualcosa sul client che a sua volta comporta la necessità di aggiornare diversi altri elementi.

Forse abbiamo un'app che simula le persone in fila. Ogni persona ha una posizione nella linea. L'utente ha la possibilità di eliminare una persona dalla linea che risulta in due azioni. Per prima cosa, elimina la persona dal database. Secondo, aggiorna le persone rimanenti nel database per riflettere la loro nuova posizione nella linea. (Questa è una semplice illustrazione, ma potrebbero essere necessari ulteriori aggiornamenti del database per altre tabelle db non di persona).

Ciò dovrebbe essere fatto in due richieste Ajax separate? Invia prima la richiesta DELETE e se il server risponde con un messaggio di successo, quindi invia una richiesta PATCH per aggiornare le posizioni rimanenti. O entrambi dovrebbero essere combinati in un'unica chiamata ajax?

Il motivo per cui lo chiedo è perché fare due richieste separate sarebbe più RESTful dal punto di vista dell'API. vale a dire: inviare una richiesta DELETE per un singolo oggetto, ottenere una risposta positiva sul client, quindi inviare una richiesta PATCH per più oggetti. Gli URL per quelli sarebbero conformi alle tipiche strutture RESTful.

Tuttavia, se si combinano tali richieste in una sola cosa significa che si deve avere un endpoint API che certamente non è RESTful eliminando e rattoppando più elementi in un'unica chiamata. Inoltre, non userebbe una tipica struttura URL. Ma si finisce con una sola chiamata al server e una risposta che conferma che tutto è stato fatto.

Quindi la mia domanda è, quando crei SPA con interazioni abbastanza complesse rispetto alla creazione / eliminazione / aggiornamento di più oggetti contemporaneamente, dovremmo provare a essere RESTful nel modo in cui l'API viene creata e utilizzata o creiamo API endpoint che fanno esattamente ciò che è necessario in una singola chiamata al server?

    
posta darkpool 03.06.2018 - 14:28
fonte

2 risposte

6

Breve asnwer: fallo nel back-end.

In pratica, è strategicamente più intelligente eseguire tutte le operazioni, in pratica una transazione, in un servizio di back-end:

  • I backend e i relativi endpoint API rappresentano di solito una sorta di portale nel modello dati. Parlando in modo semplice, l'API spesso è uno strumento per leggere e scrivere da / in un database. Solitamente nel back-end, ad es. in un linguaggio come Node, Ruby, Go, Java ecc., hai il controllo su cose che potrebbero andare storte. Una delle operazioni potrebbe non riuscire e si desidera assicurarsi che il modello di dati rimanga coerente eseguendo il rollback / ripristino delle operazioni precedenti. Questo è molto difficile dal frontend. L'utente potrebbe semplicemente chiudere il browser o disconnettersi da Internet durante due richieste e non esiste un modo affidabile di rilevamento.
  • Potresti aggiungere un altro frontend, ad esempio un'app per iOS oltre all'app Web esistente. Ovviamente vuoi utilizzare la stessa API e ridurre il codice ridondante.

Ho fatto l'esperienza che vedere un frontend come utente "stupido" di un backend "intelligente" aiuta a mantenere grandi codebase di frontend soggetti a frequenti cambiamenti.

    
risposta data 03.06.2018 - 19:24
fonte
2

La logica aziendale dovrebbe essere eseguita nel back-end. Quello che stai descrivendo coinvolgerà più di una richiesta HTTP, che può influire sulle prestazioni. Riconoscere il numero di richieste HTTP è cruciale per le applicazioni a singola pagina.

    
risposta data 04.06.2018 - 02:24
fonte

Leggi altre domande sui tag