È questo "anti-pattern" e dovrei smettere di usarlo o è questo design intelligente?

Se si richiede una risorsa e non contiene i dati, allora non si tratta del servizio REST. Il servizio che fornisce i dati effettivi in JSON potrebbe essere, ma la parte HTML non lo è. Per un'applicazione web non ha importanza.

La tecnica funziona, ma devi essere consapevole delle sue limitazioni:

1. I motori di ricerca non interpretano JavaScript, quindi il sito implementato in quel modo non sarà indicizzabile da Google e simili. Per l'applicazione interna non ha importanza, per il pubblico di fronte a uno sarebbe molto importante.
2. Gli utenti con esigenze particolari (come quelli che utilizzano terminali Braille) utilizzano browser speciali che sono piuttosto limitati e potrebbero non interpretare correttamente il codice JavaScript.

Vorrei anche notare che il codice che genera l'HTML è fondamentalmente lo stesso sia che venga eseguito lato server o lato client. Hai una scelta molto più ampia di linguaggi e framework sul lato server e sono sicuro che ci sono diversi equivalenti di slickgrid.

È possibile e dovrebbe mantenere la separazione dei dati e la visualizzazione sul lato server. Il sistema di template può, e dovrebbe, semplicemente prendere i dati come struttura dei dati o persino json (specialmente se il servizio effettivo è in una lingua diversa da quella del template) e semplicemente espandere un template con quei dati.

E no, non sto pensando a PHP; è il sistema di template meno capace là fuori (anche se ce ne sono alcuni migliori costruiti sopra di esso). Sto pensando Genshi o XSLT o qualcosa di ancora più avanzato che fornisce i widget web.

Non c'è niente di sbagliato nel fare questo, a patto che tu ti assicuri di strutturare il tuo codice in modo pulito. Puoi persino pubblicare il contenuto statico, ad es. un Apache piuttosto che il tuo servizio web.

Questa è una buona pratica. Ed è sempre fatto, come dice @JanHudec, definendolo un servizio REST sbagliato. Ma molti siti Web fanno esattamente questo per i motivi che esigi.

Non lo chiamerei anti-pattern, quello che stai descrivendo è più o meno un fat client , non totalmente diverso da servizi come Trello. La responsabilità iniziale del server è quella di inviare il DOM e tutte le risorse necessarie per far funzionare il client. Ho lavorato su progetti simili nell'automazione del data center e nel monitoraggio della rete.

Il client si avvia come un DOM sparse, recupera alcuni dati tramite XHR (a volte tramite JSONP) e infine si collega a un server socket. Un esempio ancora più semplice sarebbe un'applicazione di chat.

L'unica ragione per cui non è che può essere estremamente difficile ottenere il giusto. Se sei a tuo agio con la programmazione funzionale asincrona e tutte le gare e le altre sfide che può presentare, non avrai problemi a mantenerlo. Ancora più importante, non avrai problemi a scriverlo in modo che le altre persone possano eventualmente mantenerlo.

Se il pensiero di aggiungere altre funzioni inizia a spaventarti, o inizi a scoprire che il debug è un incubo, allora potresti prendere in considerazione altri metodi in produzione mentre continui a sperimentare e imparare.

È un disegno valido finché non stai scavando una buca per te stesso. Se hai gozzi e gocce di JS casuali dappertutto invece di un'interfaccia pulita, probabilmente vorrai rifare il fattore o andare sul progetto in modo diverso. La maggior parte delle tue funzioni che vengono definite da eseguire una volta che tutte le risorse caricate devono essere anonime e immesse da un'interfaccia pulita. Se non lo sono, potresti essere in cerca di guai.

come ha detto @Jan Hudec, il tuo approccio non può essere definito REST. Sebbene la parte in cui il cliente richiede una risorsa potrebbe essere. È meglio se il client gestisce la parte di presentazione, come fa backbone . Comunica con il server REST per le risorse e le visualizza utilizzando views .

Potrebbe essere un anti-pattern, ma penso che sia anche il futuro delle applicazioni web. Piuttosto che masticare con JavaScript, tuttavia, dovresti usare almeno una libreria di template. Una soluzione migliore è un framework MVC lato client come AngularJS (che mi capita di usare ora).

Per ulteriori riferimenti, ecco un popolare post di blog confrontando diversi framework e ecco un sito che implementa lo stesso programma utilizzando più framework.

Inoltre: i commenti di Jan Hudec sull'interazione tra motori di ricerca e screen reader sono validi. Se stai lavorando su un sito di e-commerce (dove il pagerank è importante), probabilmente non vuoi usare i framework lato client. Ma per le app interne, di solito non ci sono problemi.

Ciò che il tuo lavoro sembra buono! Tuttavia, se le tue risposte JSON contengono HTML, perdi tempo.

Un altro punto è che il tuo stupido cliente dovrebbe probabilmente ottenere i suoi dati JSON da un progetto diverso. Dovresti mirare a una corretta separazione tra cliente e servizio, quindi avrai un servizio RESTful adeguato