Stiamo iniziando a creare una nuova app e vorrei esplorare l'idea di creare un client JS di spessore (backbone / angolare) con solo API RESTful esposte dal nostro livello di applicazione. Quali sono alcune delle migliori pratiche e potenziali insidie per fare questo tipo di app web?
Se hai solo un'API REST (e nessuna "pagina" lato server effettiva), le maggiori sfide che ti vengono in mente sono:
Accessibilità
È triste, ma la maggior parte degli screen reader è molto indietro nel tempo e non può ancora gestire i contenuti dinamici. La soluzione moderna è WAI-ARIA , ed è una curva di apprendimento ripida.
Indicizzazione (SEO)
Per Googlebot e altri spider, il tuo sito è essenzialmente una pagina vuota. Se hai bisogno di indicizzare il contenuto, dovrai fare di più. Per le API veramente "nude" che non pubblicano affatto HTML, probabilmente vorrai seguire la raccomandazione di Google di utilizzare il tuo ragno in grado di scattare JavaScript per scattare istantanee di pagine e pubblicare link hashbang.
Transazioni tra risorse diverse
Non tutti i flussi di lavoro saranno incapsulati in modo pulito da una singola risorsa. Potrebbe essere necessario aggiornare una / fattura e / account allo stesso tempo. Non ci sono ancora standard reali per questo; la risposta tipica sembra essere quella di incapsulare la transazione stessa come una risorsa e gestire l'atomicità nell'API REST per la risorsa di transazione. Un carrello della spesa è un buon esempio di una transazione; una volta effettuato il checkout, l'intero paniere viene "impegnato" in una sola volta.
Ottimizzazione web
Stai prendendo più di 10 volte la quantità di JavaScript che si trova nelle app web più convenzionali. Tutto di questo deve essere servito al client ed eseguito ad un certo punto, quindi la minimizzazione e l'ottimizzazione delle prestazioni non sono opzionali, e può essere più difficile ottimizzare il client rispetto al server se si considera che alcuni i tuoi utenti continueranno a utilizzare IE8 o IE7 su Windows XP su una macchina AMD Athlon originale che il loro nipote ha costruito per loro 7 anni fa. Inoltre, dal momento che cambierai frequentemente i tuoi script, non puoi solo ridimensionare, devi anche versione , altrimenti la tua app si romperà misteriosamente a causa del caching e .
Gestione degli errori
La maggior parte dei framework web di back-end ha questo built-in. Basta collegare un gestore di eccezioni globale, alcune registrazioni, pagine di errore personalizzate e il gioco è fatto. Può essere piuttosto difficile farlo in JavaScript. Puoi collegare un gestore di errori globale a $.ajax o qualsiasi altra cosa, ma anche questo è pieno di problemi, dal momento che alcuni codici di errore hanno un significato semantico (404, 409, ecc.). Supponendo che tu sia disposto ad andare allo sforzo di impostando un'API di registrazione per raccogliere errori, dovrai fare un compromesso tra verbosità e larghezza di banda, e anche mettere un qualche tipo di sicurezza o limitazione di velocità su di esso in modo che le persone non possano semplicemente inviare spam all'API di registrazione a DoS. sito.
Test
Almeno nella mia esperienza, i test diventano più difficili perché è necessario mantenere suite parallele di test unitari per client e server. Se esegui test di integrazione basati su browser, sarà più difficile stabilire se gli errori provengono dal lato client o server, a meno che tu non mantenga anche una altra suite di test di integrazione solo API. In pratica, è come aggiungere un altro "tier".
autenticazione / autorizzazione
Ci sono standard per questo (ad esempio OAuth), ma sono difficili da implementare rispetto ai modelli più tradizionali. Ciò è particolarmente vero se si sta eseguendo un sito HTTP / HTTPS misto e si deve trattare di crap come CORS. È un problema molto risolvibile e il più basso nella mia lista per un motivo; sarà solo un lavoro extra e ti morderà in momenti strani, perché molti dei framework back-end possono essere un po '... imperiosi su come l'autenticazione dovrebbe funzionare, e sovrautilizzare le cose come lo stato della sessione.
Inoltre, la tua app sta fondamentalmente rovesciando il suo fegato a tutti coloro che la usano, rendendo banalmente semplice la retroingegnerizzazione dell'API, quindi è meglio assicurarsi di avere un sacco di validazione in atto, altrimenti qualsiasi kiddie di script casuali può Sei tu. Non che questo sia un nuovo problema, lo stai rendendo un po 'più semplice fornendo una linea diretta.
Tutto ciò che viene detto, questi non sono nemmeno vicino a essere in mostra. A parte l'esperienza utente notevolmente migliorata, ottieni enormi benefici da questo modello attraverso la riusabilità e la separazione delle preoccupazioni. Diventa molto più difficile (e molto meno necessario) per gli sviluppatori abusare dello stato della sessione o di altri dati temporanei. E puoi davvero avere specialisti front-end e back-end, piuttosto che dover esporre i tuoi back-end a markup o i tuoi front-end ai controller.
Preferisco di gran lunga questa architettura ma sono consapevole dei compromessi che stai facendo. È ancora una specie di campo nuovo / immaturo e le persone continuano a commettere molti errori. Non mi fiderei di alcuna guida sulle "migliori pratiche" all'inizio del gioco.
Leggi altre domande sui tag api rest web-applications