¿REST es una buena opción para las aplicaciones web GUI?

Question

Las aplicaciones web basadas en GUI se pueden construir a partir de un componente GUI, un marco con estado como Wicket o podrían compilarse de manera RESTful, sin estado, con el estado de la GUI solo en el cliente.

Desde el punto de vista técnico, REST se ve como el camino correcto, ya que aprovecha toda la potencia de http y conduce a aplicaciones altamente escalables. Pero eso tiene un precio. Las GUI complejas requerirán una aplicación de JavaScript en el cliente en muchos casos. Debe permanecer en la misma página y volver a cargar solo las partes, si el estado debe mantenerse en el cliente. O tienes que usar trucos con iframes escondidos. Algunas veces hay carros de compras de pseudo recursos en el servidor para habilitar un diseño RESTful. Debe mantener el estado intermedio de los diálogos multipaso, etc.

Si miro a su alrededor, hay muy pocas aplicaciones de GUI RESTful. ¿Es esto por razones históricas o es un diseño RESTful improductivo en escenarios comunes?

Answer 1

Los diseños RESTful GUI son muy productivos, en mi humilde opinión. Puede aprovechar una gran cantidad de funcionalidades sin trabajo adicional para respaldar los casos de esquina, como el usuario que vuelve a enviar la información, el historial del navegador (hacia atrás y hacia adelante), varias pestañas y ventanas. Si no me equivoco, este sitio utiliza una interfaz de usuario RESTful.

Answer 2

REST se definió observando las características de las aplicaciones web exitosas, tanto GUI como M2M. Por lo tanto, por definición, debería ser apropiado para estos casos.

También noté que hizo una pregunta con respecto a desktop versus web applications. Le puede interesar saber que REST también es una excelente arquitectura para crear aplicaciones cliente de escritorio. He escrito algunos clientes de escritorio que obtienen todos sus datos de un servidor REST.

Answer 3

Si miro a mi alrededor hay muy pocas aplicaciones GUI RESTful. ¿Es esto debido a razones históricas o es un diseño RESTful improductivo en escenarios comunes ?

Mi respuesta es subjetiva, pero en mi opinión, dos grandes obstáculos entorpecen el desarrollo REST:

1. cambio - que es muy diferente de la forma en sitios están diseñados tradicionalmente
2. Challenge - el diseño de una pura REST API del servidor y la correspondiente, robusta interfaz de usuario de cliente rico no es fácil

interfaces gráficas complejas requerirán un JavaScript aplicación en el cliente en muchos casos .

En mi opinión, una experiencia compleja, rica en el lado del cliente va a requerir un JavaScript profundo, independientemente de la implementación del lado del servidor.

usted tiene que permanecer en la misma página y recarga sólo partes,

Esto es un diseño muy diferente de la tradicional petición/respuesta de diseño-a toda página a página completa. Cada diseño tiene sus propias compensaciones. Los diseños REST funcionan particularmente bien con las llamadas AJAX, pero el código del lado del cliente requiere un diseño cuidadoso para que sea fácil de mantener y robusto.

Un servidor REST con un cliente pesado:

• escalas así: información de sesión para cada usuario no se almacena en la memoria del servidor escasa
datos
• menos de solicitud/respuesta sobre el alambre: no enviar a cada de página en los identificadores de sesión completos, no enviar o ViewState s
• URL reutilizables limpios: proporcionan una API de servidor limpio, disociada que puede soportar múltiples interfaces de usuario
• pura: el cumplimiento estricto de la especificación HTTP (GET no causan efectos secundarios, etc.)
• experiencia del cliente: más rica, más sensible a las transacciones asíncronas

Sin embargo, a medida que se menciona gruesas-clientes tienen inconvenientes:

• más vulnerables a los ataques XSS, URLs REST realmente necesita la seguridad cuidadosa
• JavaScript complejo puede ser un desafío para desarrollar, mantener y depurar (utilizando OO JavaScript puede ayudar a mediar en esto)
• hay una necesidad de indicar al usuario que las solicitudes asincrónicas se procesan ng en el fondo se requiere
• más del lado del cliente lógica de falta de manejo de
• marcos y herramientas IDE han sido tradicionalmente más débil para el desarrollo del lado del cliente, en comparación con el lado del servidor (esto se está poniendo poco a poco mejor)