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

spring boot (7)

El estilo arquitectónico REST promueve mensajes inspeccionables (que ayudan a la depuración y la seguridad), evolución de API, plataformas múltiples, interfaces simples, recuperación de fallas, alta escalabilidad y (opcionalmente) sistemas extensibles a través del 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 la uniformidad de la plataforma, la variabilidad de la interfaz, la generación de código (y por lo tanto, la capacidad de simular que la red no existe, pero ve las Fallacies ) y las 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, use el estilo REST. Si desea lo último, use el estilo RPC.

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 la Opción A: GWT-RPC y construir la aplicación rápidamente?

Opción B: compilar un backend REST usando Spring MVC 3.0 con todas las grandiosas anotaciones @Controller, @Service, @Repository y crear una biblioteca del lado del cliente para hablar con el backend usando las funciones de superposición GWT y el generador de solicitudes GWT.

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

Hágase la pregunta: "¿Tendré que reutilizar la interfaz del lado del servidor con un front-end que no sea de GWT?"

Si la respuesta es "no, solo tendré un cliente GWT" : puede usar GWT-RPC y aprovechar el hecho de que puede usar sus objetos Java tanto en el servidor como en el lado del cliente. 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" /> , 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), tipo de 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 pertenecen a 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 envoltorios ( Tipos de superposición de JavaScript ) o código de transformación en el lado del cliente de GWT para crear objetos agradables de Java 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 ambos. 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.

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

REST es una buena idea, incluso si nunca intenta 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.

Puedes hacer ambas cosas si también utilizas 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.

Si planea usar Hibernate / JPA en el servidor y enviar los POJO resultantes con datos relacionales al cliente (es decir, un objeto Employee con una colección de teléfonos), definitivamente vaya con la 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 tengo el temido:

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 te encuentras con esto y quieres quedarte con GWT RPC, deberás usar algo como:

GWT Request Factory (www.gwtproject.org/doc/latest/DevGuideRequestFactory.html) - que te obliga a escribir 3+ clases / interfaces por POJO que quieras compartir con el cliente. ¡AY!
Gilead (sourceforge.net/projects/gilead/) - que aparece en un proyecto muerto.

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

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 backend (REST y RPC)

Si construye un backend REST adecuado, 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.

Respondiendo a los comentarios de ams: Respecto al protocolo RPC, la última vez que lo "olfateé" usando firebug no se veía como json, así que no sé nada 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.

Con respecto 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.

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.