¿Debo construir un backend REST para la aplicación GWT?

Question

Estoy planeando una nueva aplicación y he estado experimentando con GWT como una posible interfaz. La pregunta de diseño que estoy enfrentando es esta.

¿Debo usar Opción A: GWT-RPC y construir la aplicación rápida

Opción B: Construir un motor RESTO utilizando Spring MVC 3.0 con toda la gran @Controller, @Service, anotaciones @Repository y construir una la biblioteca del lado del cliente para hablar con el back-end utilizando las características de superposición GWT y el generador de solicitudes GWT?

Me interesan todos los pros y contras y las experiencias de las personas con este tipo de diseño?

Answer 1

Hazte la pregunta: "¿Tendré que volver a utilizar la interfaz del lado del servidor con un front-end que no sea de GWT?"

Si la respuesta es "no, voy a tener un cliente GWT": Puede utilizar GWT-RPC, y aprovechar el hecho de que se puede utilizar objetos de Java, tanto en el servidor y el cliente -lado. Esto también puede hacer que la comunicación sea un poco más eficiente, al menos cuando se usa con <inherits name="com.google.gwt.user.RemoteServiceObfuscateTypeNames" />, lo que acorta los nombres de tipo a pequeños valores numéricos. También obtendrá la ventaja de un mejor manejo de errores (usando Excepciones), escriba seguridad, etc.

Si la respuesta es "sí, haré que mi servicio sea accesible para múltiples tipos de interfaces": Puede usar REST con JSON (o XML), que también puede ser entendido por clientes que no son de GWT. Además de cambiar clientes, esto también le permitiría cambiar a una implementación de servidor diferente (tal vez no Java) en el futuro más fácilmente. La desventaja es que probablemente tendrá que escribir wrappers (JavaScript Overlay Types) o código de transformación en el lado del cliente GWT para construir objetos Java agradables a partir de los objetos JSON. Deberá tener especial cuidado cuando implemente una nueva versión del servicio, lo que nos devuelve a la falta de seguridad de tipo.

La tercera opción, por supuesto, sería construir ambas. Elegiría esta opción, si la interfaz REST pública fuera diferente de la interfaz GWT-RPC de todos modos, tal vez proporcionando solo un subconjunto de servicios fáciles de usar.

Answer 2

Yo diría que esto depende del alcance de su aplicación total. Si su back-end debe ser utilizado por otros clientes, debe ser extensible, etc. luego, cree un módulo por separado utilizando REST. Si el backend solo debe ser utilizado por este cliente, entonces elija la solución GWT-RPC.

Answer 3

Yo diría construir un backend REST. En mi último proyecto comenzamos desarrollando usando GWT-RPC durante los primeros meses, queríamos un rápido arranque. Más adelante, cuando necesitábamos la API REST, era tan costoso hacer la refactorización que terminamos con dos API de back-end (REST y RPC)

Si construyes un backend REST apropiado, y una infraestructuralización infra en el lado del cliente (para transformar el json \ xml en objetos GWT Java), entonces el beneficio del RPC es casi nulo.

Otra ventaja a veces olvidada del enfoque REST es que es más natural para el navegador que ejecuta el cliente, RPC es un protocolo propiciatorio, donde todas las solicitudes usan POST. Puede beneficiarse del almacenamiento en caché del lado del cliente al leer recursos de la manera estándar.

Contestación comentarios AMS: con respecto al protocolo RPC, última vez que "olieron" usando Firebug que no se veía como JSON, por lo que no saben de eso.Sin embargo, incluso si está basado en json, todavía utiliza solo el método HTTP POST para comunicarse con el servidor, por lo que mi punto aquí sobre el almacenamiento en caché sigue siendo válido, el navegador no almacenará en caché las solicitudes POST.

En cuanto a la retrospectiva y lo que podría haber sido mejor, escribir el servicio RPC en una arquitectura orientada a recursos podría llevar más tarde a una migración más fácil a REST. recuerde que en REST normalmente se exponen los recursos con las operaciones CRUD básicas, si se enfoca en ese enfoque al escribir el servicio RPC, entonces debería estar bien.

Answer 4

El estilo arquitectónico REST promueve mensajes inspeccionables (que ayudan a la depuración y la seguridad), evolución API, plataformas múltiples, interfaces simples, recuperación de fallas, alta escalabilidad y (opcionalmente) sistemas extensibles mediante código bajo demanda. Negocia el rendimiento por interacción para la eficiencia general de la red. Reduce el control del servidor sobre el comportamiento consistente de la aplicación.

El "estilo RPC" (como decimos en oposición a REST) ​​promueve uniformidad de plataforma, variabilidad de interfaz, generación de código (y por lo tanto la capacidad de simular que la red no existe, pero vea Fallacies), y interacciones personalizadas. Negocia la eficiencia general de la red para un alto rendimiento por interacción. Aumenta el control del servidor sobre el comportamiento consistente de la aplicación.

Si su aplicación desea las cualidades anteriores, utilice el estilo REST. Si desea lo último, use el estilo RPC.

Answer 5

Puede hacer ambas cosas si también utiliza el proyecto RestyGWT. Hará que llamar a los recursos JSON basados ​​en REST sea tan fácil como usar GWT-RPC. Además, normalmente puede reutilizar las mismas DTO de respuesta de solicitud del lado del servidor en el lado del cliente.

Answer 6

Nos encontramos con el mismo problema cuando creamos el Spiffy UI Framework. Elegimos REST y nunca volvería. Incluso diría que GWT-RPC es un GWT Anti-pattern.

REST es una buena idea, incluso si nunca tiene la intención de exponer sus puntos finales REST. Crear una API REST hará que su UI sea más rápida, su API sea mejor y toda su aplicación sea más fácil de mantener.

Answer 7

Si está planeando usar Hibernate/JPA en el servidor y enviar los POJO resultantes con datos relacionales al cliente (es decir, un objeto Empleado con una colección de Teléfonos), definitivamente vaya con el Implementación de REST.

Empecé mi proyecto GWT hace un mes usando GWT RPC. Todo estuvo bien hasta que intenté serializar un objeto del archivo base subyacente con una relación One-To-Many. Y consiguió la temida:

com.google.gwt.user.client.rpc.SerializationException: Type 'org.hibernate.collection.PersistentList' was not included in the set of types which can be serialized by this SerializationPolicy 

Si se encuentra con esto y quiere quedarse con GWT de RPC que tendrá que usar algo como:

• GWT Solicitud de fábrica (www.gwtproject.org/doc/latest /DevGuideRequestFactory.html) - lo cual obliga a escribir 3+ clases/interfaces por POJO que desee compartir con el cliente. ¡OUCH!
• Gilead (sourceforge.net/projects/gilead/) - que parece un proyecto muerto.

Ahora estoy usando RestyGWT. El cambio fue bastante sencillo y mi POJO se serializa sin problemas.