¿Es este "antipatrón" y debo dejar de usarlo o es un diseño inteligente?

Básicamente me he propuesto hacer lo siguiente al crear un servicio REST:

1. Se solicita HTML
2. El servicio devuelve la página web deseada pero sin el "recurso" solicitado, por ejemplo. datos
3. la página web contiene JavaScript que emite una solicitud AJAX al mismo servicio (diferente tipo de contenido)
4. el servicio luego devuelve los datos reales (JSON) y la página lo muestra

Por un lado, parece ineficiente (2 solicitudes), pero luego, cuando lo usé, "el rendimiento no es una preocupación", lo que significa que la aplicación interna de bajo tráfico y los sitios web son simples y se cargan rápidamente.

La razón por la que terminé con esto es que la página web puede ser Html + JavaScript casi pura y casi no se requieren elementos del lado del servidor, especialmente sin bucles, para crear tablas y cosas por el estilo (lo que creo que es muy feo en comparación con cosas como slickgrid), por ejemplo, separación de datos y vista.

Ahora, antes de comenzar a usar esto, ¿es una buena idea o debería dejar de hacerlo?

Si solicita un recurso y no contiene los datos, entonces no es el servicio REST. El servicio que proporciona los datos reales en json puede ser, pero la parte HTML no lo es. Para una aplicación web no importa.

La técnica funciona, pero debe tener en cuenta sus limitaciones:

1. Los motores de búsqueda no interpretan JavaScript, por lo que Google y sus "Me gusta" no podrán indexar el sitio implementado de esa manera. Para la aplicación interna no importa, para el público frente a uno sí que importaría mucho.
2. Los usuarios con necesidades especiales (como los que usan terminales Braille) usan navegadores especiales que son bastante limitados y pueden no interpretar el JavaScript correctamente.

También me gustaría señalar que el código que genera el HTML es básicamente el mismo, ya sea que se ejecute del lado del servidor o del lado del cliente. Tiene muchas más opciones de idiomas y marcos en el lado del servidor y estoy seguro de que también hay varios equivalentes de slickgrid.

Puede y debe mantener la separación de datos y la visualización en el lado del servidor. El sistema de plantillas puede y debe simplemente tomar los datos como estructura de datos o incluso json (especialmente si el servicio real está en un idioma diferente al sistema de plantillas) y simplemente expandir una plantilla con esos datos.

Y no, no estoy pensando en PHP; es el sistema de plantillas menos capaz que existe (aunque hay algunos mejores construidos encima). Estoy pensando en Genshi o XSLT o algo aún más avanzado que proporciona widgets web.

No hay nada de malo en hacer esto, siempre y cuando se asegure de estructurar su código limpiamente. Incluso puede servir el contenido estático de, por ejemplo, un Apache en lugar de su servicio web.

Esta es una buena práctica. Y se hace todo el tiempo, aunque como lo señala @JanHudec, llamarlo un servicio REST está mal. Pero muchos sitios web hacen exactamente esto por exactamente las razones que usted señala.

No lo llamaría un antipatrón, lo que estás describiendo es más o menos un cliente gordo , no muy diferente de servicios como Trello. La responsabilidad inicial del servidor es enviar el DOM y los recursos necesarios para que el cliente funcione. He trabajado en proyectos similares en automatización de centros de datos y monitoreo de redes.

El cliente comienza como un DOM disperso, extrae algunos datos a través de XHR (a veces a través de JSONP) y finalmente se conecta a un servidor de socket. Un ejemplo aún más básico sería una aplicación de chat.

La única razón por la que no hacerlo es que puede ser extremadamente difícil de hacerlo bien. Si se siente cómodo con la programación funcional asíncrona y todas las carreras y otros desafíos que puede presentar, entonces no tendrá problemas para mantenerla. Más importante aún, no tendrá problemas para escribirlo para que otras personas puedan mantenerlo.

Si la idea de agregar más funciones comienza a asustarlo, o si comienza a descubrir que la depuración es una pesadilla, es posible que desee considerar otros métodos de producción mientras continúa experimentando y aprendiendo.

Es un diseño válido siempre que no estés cavando un agujero por ti mismo. Si tiene montones y montones de JS aleatorios en todas partes en lugar de una interfaz limpia, entonces probablemente desee re-factorizar o realizar el proyecto de manera diferente. La mayoría de las funciones que están definidas para ejecutarse una vez que se cargan todos los recursos deben ser anónimas e ingresadas desde una interfaz limpia. Si no lo son, es posible que tengas problemas.

como dijo @Jan Hudec, su enfoque definitivamente no se puede llamar REST. Aunque la parte donde el cliente solicita un recurso podría ser. Es mejor si el cliente maneja la parte de la presentación, como lo backbonehace. Se comunica con el servidor REST para obtener los recursos y los muestra usando views.

Puede ser un antipatrón, pero creo que también es el futuro de las aplicaciones web. Sin embargo, en lugar de burlarse de JavaScript, debería utilizar al menos una biblioteca de plantillas. Una mejor solución es un marco MVC del lado del cliente como AngularJS (que estoy usando ahora).

Para algunas referencias más, aquí hay una publicación de blog popular que compara varios marcos, y aquí hay un sitio que implementa el mismo programa usando múltiples marcos.

También: los comentarios de Jan Hudec sobre la interacción del motor de búsqueda y los lectores de pantalla son válidos. Si está trabajando en un sitio de comercio electrónico (donde el pagerank es importante), entonces probablemente no desee usar marcos del lado del cliente. Pero para las aplicaciones internas, estas no suelen ser preocupaciones.

¡Lo que estás haciendo suena bien! Sin embargo, si sus respuestas json contienen HTML, está perdiendo el tiempo.

Sin embargo, otro punto es que su cliente tonto probablemente debería obtener sus datos json de un proyecto diferente. Debe buscar una separación adecuada entre el cliente y el servicio, entonces tendrá un servicio RESTful adecuado