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

Question

Я нахожусь в процессе разработки многофункционального интернет-приложения, которое взаимодействует с (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, который бы сделал ОЧЕНЬ мало предположений о модели данных и операциях, которые можно выполнить.Это может уменьшить количество усилий по поддержке клиента за счет изменений в серверной части, , но имеет ли это смысл?перевешивает ли выгода?

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

Answer 1

Это отличный философский вопрос. Мой общий ответ: следует ожидать некоторой связи .

Позвольте мне объяснить больше. Несмотря на то, что можно представить себе полностью универсальный интерфейс приложения, который просто демонстрирует модель в удобной для человека форме, на самом деле невероятно сложно написать такой программный продукт, за исключением действительно незначительных доменов (например, заполнение записи, которая будет использоваться для заполнить базу данных, где все поля выбираются из конечных простых перечислений). Если ваше приложение не подходит для этой модели, вам понадобится что-то конкретное для приложения. Если вы сделаете это «универсальным» способом, вы загрузите сложное описание того, что должно делать ваше универсальное клиентское приложение, и само это описание будет все больше и больше походить на язык программирования. Теперь вы вернулись к исходной точке, кроме как с (возможно, плохо спроектированным) новым специфичным для домена языком в миксе. С таким же успехом вы можете пойти на погоню и согласиться с тем, что полностью универсальный подход не имеет смысла.

Но это не значит, что вам не следует тщательно продумывать, какие ресурсы вы раскрываете, какие глаголы применяются к этим операциям и как программное обеспечение пользователей обнаруживает эти ресурсы. После REST и HATEOAS это очень поможет (и это поможет, если у вас есть четкое представление о том, какова основная абстрактная модель приложения; вы должны стремиться показать это естественным образом).

Answer 2

Учитывая, что приложение GWT обслуживается по протоколу HTTP, его тесная связь с сервером не нарушает HATEOAS. Это «код по требованию».

Google, Twitter и Facebook используют специальные API для своего приложения, отличные от тех, которые доступны третьим сторонам (Twitter недавно перешел на использование своего открытого API для своего веб-приложения, но изначально это не имело место). Google сказал, что они не планируют переход G + на его общедоступный API, потому что он позволяет им экспериментировать и вносить серьезные изменения, не нарушая третьих сторон.