GWT Rich Internet Application (RIA) и REST HATEOAS - насколько они совместимы?

Я занимаюсь разработкой многофункционального веб-приложения в Интернете, которое взаимодействует с серверной частью (Java) через веб-службы. Я создал прототип пользовательского интерфейса как в Flex / Flash, так и в GWT / Javascript, и заметил, что эти платформы RIA, как правило, предпочитают метод внутренней связи в стиле RPC (AMF для Flex и GWT-RPC для GWT).

В моем случае сервер также должен предоставлять веб-службы другим клиентам, автора которых я не являюсь. Из-за этого я склоняюсь к стандартным веб-службам (например, SOAP и REST). Я убежден, что RIA должно использовать тот же веб-сервис, который мы предоставляем другим. Я «получаю» протокол SOAP, потому что он моделирует стиль RPC, с которым я знаком по опыту. Я новичок в REST, но создал прототип серверной части REST с помощью CXF / Jackson. Однако в настоящее время мой REST API все еще ощущается как API-интерфейс в стиле RPC, и я понимаю, что это потому, что у меня возникли проблемы с осмыслением идеи HATEOAS.

Я читал полезную запись в блоге Роя Т. Филдингса около 10 раз, и я думаю, что начинаю видеть свет. Например, мне ясно, что если бы я включил ссылки на различные переходы между состояниями вместе с моим ресурсом, я действительно мог бы уменьшить степень связи между моим клиентом и сервером. Мой клиент мог просто отображать кнопки, которые предоставляют пользователю доступ к юридическим операциям, которые могут быть выполнены с отображаемым объектом в это время.

Но имеет ли значение слабая связь между RIA и его серверным приложением?

По самой своей природе RIA довольно тесно связаны с серверной моделью данных. Из коробки они предполагают многое. Я предполагаю, что именно поэтому они также предпочитают протокол приложений в стиле RPC ... потому что слабая связь не является целью дизайна. Но я начинаю понимать, что если бы мы серьезно отнеслись к HATEOAS, мы могли бы написать гораздо более общий клиент RIA, который делал бы ОЧЕНЬ мало предположений о модели данных и операциях, которые могут быть выполнены. Это могло бы уменьшить количество усилий по поддержке клиента за счет изменений в серверной части, , но имеет ли это смысл? перевешивает ли выгода затраты?

p.s. - Еще две детали. Это приложение имеет чрезвычайно сложную, глубоко вложенную модель данных. Кроме того, мне все равно, если кто-то скажет мне, что мы не на 100% чистое веб-приложение REST.