Должен ли я создать сервер REST для приложения GWT

Ответ 1

Задайте себе вопрос: "Нужно ли мне повторно использовать интерфейс на стороне сервера с интерфейсом без GWT?"

Если ответ "нет, у меня будет только клиент GWT" : вы можете использовать GWT-RPC и воспользоваться тем фактом, что вы можете использовать ваши объекты Java как на сервером и клиентской стороной. Это также может сделать сообщение более эффективным, по крайней мере, при использовании с <inherits name="com.google.gwt.user.RemoteServiceObfuscateTypeNames" />, что сокращает имена типов до небольших числовых значений. Вы также получите преимущество в улучшении обработки ошибок (с использованием исключений), безопасности типов и т.д.

Если ответ "да, я сделаю доступную услугу для нескольких типов интерфейсов" . Вы можете использовать REST с JSON (или XML), что также можно понять не-GWT клиентов. В дополнение к переключению клиентов это также позволит вам легче переключиться на другую реализацию сервера (возможно, не Java) в будущем. Недостатком является то, что вам, вероятно, придется писать обертки (Типы перекрытия JavaScript) или код преобразования на стороне клиента GWT для создания красивых объектов Java из объектов JSON. Вы должны быть особенно осторожны при развертывании новой версии сервиса, что возвращает нас к отсутствию безопасности типов.

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

Ответ 2

Вы можете сделать это, если вы также используете проект RestyGWT. Это позволит использовать ресурсы JSON на основе REST, как легко использовать GWT-RPC. Кроме того, вы можете, как правило, повторно использовать те же запросы DTO ответа с сервера на стороне клиента.

Ответ 3

Мы столкнулись с той же проблемой, когда создали Spiffy UI Framework. Мы выбрали REST, и я никогда не вернусь. Я бы даже сказал, что GWT-RPC - это GWT Anti-pattern.

REST - хорошая идея, даже если вы никогда не намереваетесь показывать свои конечные точки REST. Создание REST API сделает ваш пользовательский интерфейс более быстрым, ваш API лучше, и все ваше приложение будет более удобным.

Ответ 4

Я бы сказал, постройте бэкэнд REST. В моем последнем проекте мы начали с разработки с использованием GWT-RPC в течение первых нескольких месяцев, мы хотели бы ускорить загрузку. Позже, когда нам нужен REST API, было так дорого сделать рефакторинг, в котором мы закончили с двумя API-интерфейсами (REST и RPC)

Если вы создадите правильный сервер REST и уменьшите размер десериализации на стороне клиента (чтобы преобразовать json\xml в объекты GWT Java), то преимущество RPC почти ничего.

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

Ответные комментарии: Что касается протокола RPC, в прошлый раз я "обнюхал" его, используя firebug, это не выглядело как json, поэтому я не знаю об этом. Хотя, даже если он основан на json, он по-прежнему использует только HTTP-метод POST для связи с сервером, поэтому моя точка зрения о кешировании по-прежнему действительна, браузер не будет кэшировать POST-запросы.

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

Ответ 5

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

"Стиль RPC" (поскольку мы говорим об этом в противовес REST) ​​способствует равномерности платформы, изменчивости интерфейса, генерации кода (и, следовательно, возможности делать вид, что сеть не существует, но см. Fallacies) и настраиваемых взаимодействий. Он обеспечивает общую эффективность сети для высокой производительности за взаимодействие. Это увеличивает контроль сервера над последовательным поведением приложения.

Если ваше приложение желает прежних качеств, используйте стиль REST. Если он желает последнего, используйте стиль RPC.

Ответ 6

Если вы планируете использовать Hibernate/JPA на стороне сервера и отправляете полученный POJO с реляционными данными в них клиенту (т.е. объект Employee с коллекцией телефонов), обязательно отправляйтесь в REST реализация.

Я начал свой проект GWT месяц назад, используя GWT RPC. Все было хорошо, пока я не попытался сериализовать объект из базового db с отношением "один-ко-многим" в нем. И получил страшный:

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

Если вы столкнулись с этим и хотите остаться с GWT RPC, вам нужно будет использовать что-то вроде:

• Запрос GWT Factory (www.gwtproject.org/doc/latest/DevGuideRequestFactory.html) - который заставляет вас писать 3+ классы/интерфейсы на POJO, которые вы хотите поделиться с клиентом. ОЙ!
• Gilead (sourceforge.net/projects/gilead/) - который кажется мертвым проектом.

Теперь я использую RestyGWT. Коммутатор был довольно безболезненным, и моя POJO сериализовалась без проблем.

Ответ 7

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