Pregunta ¿Cuál es la mejor manera de diseñar un servidor GWT "independiente de la plataforma"?


¿Cuál es la mejor manera de diseñar una arquitectura de servidor Java que interactúa con una aplicación GWT del lado del cliente, pero también responde correctamente a varias otras solicitudes de clientes desde otras plataformas? Específicamente, me gustaría usar la misma capa de servlet para responder no solo a mi aplicación GWT, sino a las aplicaciones iOS y Android correspondientes.

El primer enfoque que pensé sería implementar la capa de cliente GWT utilizando "RequestBuilder" en lugar de las interfaces de servicio de método RPC habituales. Usando este enfoque, pude codificar los servlets genéricos que responden a las solicitudes HTTP de manera RESTful mediante el procesamiento de variables codificadas en algo como JSON o XML. Aunque esto funcionaría, sería un poco laborioso tener que codificar y decodificar mis objetos / parámetros en JSON tanto en el cliente como en el servidor, especialmente cuando RPC proporcionaba una solución tan elegante.

El otro enfoque (que creo que es mejor) sería encontrar la especificación que Google usa para serializar y deserializar sus llamadas al método RPC e implementar algún tipo de biblioteca que haga lo mismo para iOS (en Objective-C) y Android. El problema es que no he podido encontrar buena documentación sobre este estándar de codificación, ni he encontrado bibliotecas que lo implementen para iOS o Android (aunque encontré algo así para PHP en www.gwtphp.com).

¿Alguien podría dirigirme hacia una especificación de cómo GWT serializa / deserializa sus objetos o, mejor aún, las bibliotecas para iOS y / o Android que implementan interfaces RPC?


5
2018-01-13 22:02


origen


Respuestas:


Cree una capa de "servicio", es decir, un conjunto de clases de negocios que devuelvan POJO.

Luego puede hacer que GWT-RPC y REST llamen fácilmente a la capa de servicio.

Esto es bastante fácil y directo. Su problema será cómo crear una capa empresarial que solo devuelva POJO. Pero esa es otra historia.


4
2018-01-14 04:56



Si realmente está tratando de tener un servidor independiente de la plataforma con el que los clientes puedan interactuar, entonces su mejor opción será usar un enfoque de "mínimo denominador común", que a menudo es pasar datos simples y manejar superficies para que ocurran varias acciones. .

Para ello, una interfaz RESTful, probablemente con JSON o XML para codificar los datos, será su apuesta más compatible.

La principal ventaja de ir de esta manera es que ya hay un montón de bibliotecas que se ocupan de la serialización / deserialización de JSON y XML, y usted mantiene su servicio lo más flexible posible, lo que significa que está no limitando su base de clientes al exigirles que hagan mucho más que tratar con el texto y realizar solicitudes web (en el nivel más básico).

Eso hace trabaje un poco más para hacer que el lado del servidor de la conexión haga lo que quiera, pero esa es la compensación entre la flexibilidad de un REST bastante genérico que cualquier cliente puede manejar y un servicio RPC mucho más objetivo que, mientras hace algunos implementaciones más fáciles, hace Limite los clientes a aquellos que pueden manejar la implementación específica de RPC.


2
2018-01-13 22:25



GWT-RPC es realmente una mala opción cuando no se controla la implementación de los clientes, ya que los clientes deben actualizarse cada vez que realice un cambio en sus clases. Esta es una de las razones que llevaron al desarrollo de RequestFactory. Y funcionará como está en Android.

Dicho esto, estoy de acuerdo con Peter Knego: compilar API públicas específicas del protocolo sobre una única capa de servicio.

Además, puede usar GSON, Jackson y / o GWT AutoBeans para serializar objetos a JSON.


2
2018-01-14 14:57