Questo è "anti-pattern" e dovrei smettere di usarlo o è un design intelligente?

Fondamentalmente ho iniziato a fare quanto segue durante la creazione di un servizio REST:

1. HTML è richiesto
2. il servizio restituisce la pagina Web desiderata ma senza la "risorsa" richiesta, ad es. dati
3. la pagina web contiene JavaScript che invia la richiesta AJAX allo stesso servizio (tipo di contenuto diverso)
4. il servizio restituisce quindi i dati effettivi (JSON) e la pagina li visualizza

Da un lato sembra inefficiente (2 richieste), ma poi sono stato usato "prestazioni non preoccupano", il che significa che l'app interna a basso traffico e i siti Web sono semplici e si caricano rapidamente.

Il motivo per cui ho finito con questo è che la pagina web può essere quindi quasi pura HTML + JavaScript e non è richiesta quasi alcuna roba sul lato server, soprattutto senza loop, per creare tabelle e roba del genere (che penso sia molto brutta rispetto a cose come slickgrid), ad es. separazione dei dati e vista.

Ora, prima di usare questo, è una buona idea o dovrei semplicemente smettere di farlo?

Se si richiede una risorsa e non contiene i dati, non si tratta del servizio REST. Il servizio che fornisce i dati effettivi in ​​json potrebbe essere, ma la parte HTML no. Per un'applicazione Web non importa.

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

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

Vorrei anche notare che il codice che genera l'HTML è sostanzialmente lo stesso, indipendentemente dal fatto che funzioni lato server o lato client. Hai una scelta molto più ampia di lingue e framework sul lato server e sono sicuro che ci sono anche molti equivalenti di slickgrid.

Puoi e dovresti comunque mantenere la separazione dei dati e la visualizzazione sul lato server. Il sistema di template può, e dovrebbe, semplicemente prendere i dati come struttura di dati o addirittura json (specialmente se il servizio effettivo è in una lingua diversa rispetto al sistema di template) ed espandere semplicemente 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 a Genshi o XSLT o qualcosa di ancora più avanzato che fornisce widget web.

Non c'è niente di sbagliato nel fare questo, purché tu ti assicuri di strutturare il codice in modo pulito. Puoi persino servire il contenuto statico ad esempio da un Apache anziché dal tuo servizio web.

Questa è una buona pratica. Ed è sempre attivo, come sottolinea @JanHudec, chiamarlo servizio REST è sbagliato. Ma molti siti Web fanno esattamente questo per i motivi che sottolinea.

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

Il client inizia come un DOM sparso, estrae 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 non farlo è che può essere estremamente difficile da ottenere. 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 altre persone possano eventualmente mantenerlo.

Se il pensiero di aggiungere più funzionalità inizia a spaventarti, o inizi a scoprire che il debug è un incubo, allora potresti voler considerare altri metodi in produzione mentre continui a sperimentare e imparare.

È un design valido purché non si stia scavando un buco per te. Se hai goccioline di JS casuali dappertutto invece di un'interfaccia pulita, probabilmente vorrai ripensare o fare il progetto in modo diverso. La maggior parte delle funzioni definite per l'esecuzione una volta caricate tutte le risorse deve essere anonima e immessa da un'interfaccia pulita. Se non lo sono, potresti avere problemi.

come ha detto @Jan Hudec, il tuo approccio non può assolutamente essere chiamato REST. Anche se potrebbe essere la parte in cui il client richiede una risorsa. È meglio se il client gestisce la parte di presentazione, come backbonefa. Comunica con il server REST per le risorse e le visualizza usando views.

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

Per alcuni altri riferimenti, ecco un post sul blog popolare che confronta diversi framework, ed ecco un sito che implementa lo stesso programma usando più framework.

Inoltre: i commenti di Jan Hudec sull'interazione tra i motori di ricerca e gli screen reader sono validi. Se stai lavorando su un sito di e-commerce (dove conta la pagerank), probabilmente non vorrai utilizzare i framework lato client. Ma per le app interne, di solito non si tratta di preoccupazioni.

Quello che fai suona bene! Tuttavia, se le tue risposte json contengono HTML, allora stai perdendo tempo.

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