Каков наилучший способ разработки независимого от платформы сервера 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

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

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

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

Answer 3

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

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

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

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