Я занимаюсь разработкой многофункционального веб-приложения в Интернете, которое взаимодействует с серверной частью (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.
