Каков наилучший способ создания «независимого от платформы» GWT-сервера?

Question

Каков наилучший способ разработки архитектуры сервера Java, которая взаимодействует с клиентским приложением GWT, но также правильно реагирует на различные другие клиентские запросы с других платформ? В частности, я хотел бы использовать один и тот же уровень сервлета для ответа не только на мое приложение GWT, но и на соответствующие приложения для iOS и Android.

Первый подход, который, как я думал, заключается в реализации клиентского уровня GWT с использованием «RequestBuilder», а не обычных интерфейсов сервиса RPC-метода. Используя этот подход, я мог бы кодировать общие сервлеты, которые отвечают на запросы HTTP в RESTful, обрабатывая переменные, закодированные в чем-то вроде JSON или XML. Хотя это сработает, было бы довольно трудоемким, чтобы кодировать и декодировать мои объекты/параметры в JSON как на клиенте, так и на сервере, особенно когда RPC предоставляет такое элегантное решение.

Другой подход (который, по моему мнению, лучше), заключается в том, чтобы узнать спецификацию, которую Google использует для сериализации и десериализации вызовов метода RPC и реализации некоторой библиотеки, которая делает то же самое для iOS (в Objective-C) и Android. Проблема в том, что я не смог найти хорошую документацию об этом стандарте кодирования и не нашел библиотеки, которые реализуют ее для iOS или Android (хотя я нашел что-то подобное для PHP на www.gwtphp.com).

Может ли кто-нибудь направить меня к спецификации того, как GWT сериализует/десериализует свои объекты или, что еще лучше, библиотеки для iOS и/или Android, реализующие интерфейсы RPC?

Answer 1

Сделайте слой «обслуживания», то есть набор бизнес-классов, возвращающих POJO.

Тогда вы можете легко получить GWT-RPC и REST, называя сервисный уровень.

Это довольно легко и просто. Ваша проблема будет заключаться в том, как создать бизнес-уровень, который возвращает POJO. Но это уже другая история.

Answer 2

Если вы действительно пытаетесь создать независимый от платформы сервер, с которым могут взаимодействовать клиенты, тогда лучше всего использовать подход «наименее общий знаменатель», который часто является простым передачей данных и обработкой поверхности для различные действия.

С этой целью интерфейс RESTful, вероятно, с JSON или XML для кодирования данных, будет вашей наиболее поддерживаемой ставкой.

Основное преимущество происходит таким образом, что есть уже много библиотек, которые имеют дело с сериализации/десериализации JSON и XML, и вы храните ваши услуги как можно более гибким, что означает, что вы не ограничивая вашу клиентскую базу, требуя, чтобы они выполняли очень многое, кроме обработки текста и создания веб-запросов (на самом базовом уровне).

Это делает положил немного больше работы над тем, чтобы серверная сторона соединения выполняла то, что вы хотите, но это компромисс между гибкостью довольно общего REST, с которым может справиться любой клиент и многое другое целевая служба на основе RPC, которая, хотя и делает некоторыми реализациями, делает ограничивает клиентов теми, кто может справиться с конкретной реализацией RPC.

Answer 3

GWT-RPC действительно плохой выбор, если вы не контролируете развертывание клиентов, потому что клиенты должны обновляться каждый раз, когда вы вносите изменения в свои классы. Это одна из причин, повлекших за собой развитие RequestFactory. И он будет работать как на Android.

Это говорит о том, что я согласен с Питером Кнего: создавать публичные API-интерфейсы протокола на одном уровне обслуживания.

Кроме того, вы можете использовать GSON, Jackson и/или GWT AutoBeans для сериализации объектов в JSON.