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

Question

Я планирую новое приложение и экспериментирую с GWT в качестве возможного интерфейса.Вопрос дизайна, с которым я сталкиваюсь, заключается в следующем.

Должен ли я использовать вариант A: GWT-RPC и быстро собрать приложение

Вариант B: создать бэкэнд REST с помощью Spring MVC 3.0 со всеми@Controller, @Service, @Repository аннотации и создание библиотеки на стороне клиента для взаимодействия с бэкэндом с использованием функций наложения GWT и компоновщика запросов GWT?

Меня интересуют все плюсы и минусы и опыт людейэтот тип дизайна?

Answer 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 - возможно, предоставляя лишь подмножество простых в использовании сервисов.

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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 Request Factory (www.gwtproject.org / doc / latest / DevGuideRequestFactory.html) - который вынуждает вас написать более 3 классов / интерфейсов для каждого POJO, которым вы хотите поделиться с клиентом. OUCH!
• Gilead (sourceforge.net/projects/gilead/) - который выглядит как мертвый проект.

Я сейчас использую RestyGWT .Переключение было довольно безболезненным, и мой POJO сериализуется без проблем.

Answer 7

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