Google tiene una demostración que demuestra esta metodología a la que se refiere. Es el Autoshoppe Demo para Google App Engine. Aunque es Java, los conceptos también se aplican a las aplicaciones .NET.
La aplicación contiene páginas HTML simples de vainilla con extensiones .html. No hay tecnologías de vista lateral del servidor para complicar la vida de un programador HTML. Las páginas HTML utilizan JavaScript AJAX para interactuar con los servicios web REST creados con Spring 3.0, que interactúan con un almacén de datos.
- los datos de solicitud se pasa como JSON en la solicitud
- los datos de respuesta se devuelve como JSON en la respuesta.
Lo que esto significa es que cualquier persona puede construir una interfaz de usuario sobre esta API, o puede crear un proyecto .NET que interactúe con esa información. REST es una gran arquitectura para crear servicios extensibles y en capas.
Creo que la razón por la cual esta técnica no se usa ampliamente es porque muchas personas están atrapadas en las tecnologías de vista que alientan a los desarrolladores a utilizar el marcado de proveedor de tecnología de vista en el HTML, como archivos ASP (o JSP para Java). Es una práctica que ha existido por un tiempo porque fundamentalmente los escritores de estos marcos son ingenieros, no diseñadores web y diseñadores de interfaces de usuario.
También se necesita una comprensión bastante sólida de REST para ver las ventajas que ofrece este método, y los desarrolladores junior a veces luchan con estos conceptos.
Si tuviera que hacer frente a esto en .NET, utilizando la demostración AutoShoppe como una guía, lo más probable es que desee utilizar un asignador de objetos que puede convertir su JSON en un objeto .NET y volver a JSON. Este es un enfoque mucho más limpio que intentar analizar JSON usted mismo.
Las ventajas de este enfoque RESTful es que su contenido, comportamiento y presentación son completamente, 100% independientes, hasta el punto en que podría darle a su programador web los archivos HTML y podría ejecutarlos completamente fuera de. Entorno NETO. Sus diseñadores pueden entonces usar sus herramientas y enfocarse en sus fortalezas, sin tener que instalar, configurar o ejecutar Visual Studio.NET. De hecho, los archivos se ejecutarán directamente desde el escritorio.
EDIT: Quizás una desventaja es que no hay mucho soporte para esto en muchos frameworks MVC, principalmente porque es un concepto nuevo. El puente entre el lado del cliente y el lado del servidor actualmente debe ser escrito por el desarrollador.
En la demostración AutoShoppe, los desarrolladores escribieron una clase prototipo en JavaScript para manejar la conversión de datos a JSON antes de enviarlos al servidor, y tuvieron que escribir código JavaScript para ordenar el JSON en objetos JavaScript y manipular esos datos en HTML . En el lado del servidor, utilizaron un Object Mapper para deserializar el JSON a los objetos. La mayor parte de la complejidad estaba en el servidor.
Las ventajas de convertir el componente del servidor en un servicio RESTful 100% reutilizable con el que los diseñadores y los clientes pueden interactuar fácilmente pueden superar las desventajas, dependiendo del escenario. Un buen ejemplo puede ser para un servicio en el que se anima a sus clientes a codificar sus propias interfaces de usuario o tener control total sobre la etiqueta en blanco del producto. Esta es una de las muchas razones why I won't use server side view technologies.
Quizás porque eso no se adhiere a la "degradación elegante" y "mejora progresiva": si un usuario tiene JS deshabilitado, el sitio es 100% inutilizable. – thirtydot
No tener habilitado JS es como ejecutar Windows 3.1. Por supuesto, nada nuevo y emocionante funcionará :) Las personas con el dinero para gastar están usando navegadores habilitados para JavaScript. – jmort253
Me olvidé de JS. Espero que en 2011 puedas requerir que las personas tengan un navegador que lo use – punkouter