GWT富Internet应用程序(RIA)和REST HATEOAS - 它们的兼容性如何？

Question

我正在开发一个富Internet应用程序,通过Web服务与(Java)后端进行通信.我已经在这两个的Flex/Flash和GWT/JavaScript的原型用户界面,并已经注意到,这些RIA平台倾向于后端通信(Flex和GWT-RPC的GWT AMF)的RPC风格的方法.

在我的情况下,服务器还需要提供我没有创作的其他客户端的Web服务.因此,我倾向于基于标准的Web服务(例如SOAP和REST).我确信RIA必须使用我们为其他人提供的相同Web服务.我"得到"SOAP因为它根据经验建模我熟悉的RPC样式.我是REST新手,但使用CXF/Jackson制作了一个REST后端原型.在这个时候,然而,我的REST API仍然感觉像一个RPC风格的API,我才知道是因为我无法让我的头周围HATEOAS的想法.

我已经阅读了Roy T. Fieldings有用的博客文章大约10次,我想我开始看到了光明.例如,我很清楚,如果我要包含各种状态转换的链接以及我的资源,我可以真正减少客户端和服务器之间的耦合量.我的客户端可以只渲染按钮,使用户可以访问当时可以在显示的实体上执行的合法操作.

但RIA与其服务器应用之间的松散耦合是否重要？

就其本质而言,RIA与服务器数据模型紧密结合.开箱即用,他们预先假定许多事情.我猜这就是为什么他们也更喜欢RPC风格的应用程序协议...因为松耦合不是设计目标.但我开始意识到,如果我们认真对待HATEOAS,我们可以编写一个更通用的RIA客户端,它会对可以执行的数据模型和操作做出非常少的假设.这可以减少通过后端更改维护客户端的工作量,但这是否有意义？收益是否超过成本？

ps - 另外两个细节 - 此应用程序具有极其复杂,深度嵌套的数据模型.另外,如果有人告诉我,我们不是一个100%纯粹的REST网络应用程序,我也不在乎.

Answer 1

这是一个很棒的哲学问题。我的一般反应是应该预期会有一些耦合。

\n\n

让我解释一下。虽然可以设想一个完全通用的应用程序接口，仅以人类可用的方式公开模型，但实际上编写这样的软件非常困难，除了真正微小的领域（例如，填充将用于填充数据库，其中所有字段都是从有限的简单枚举中选取的）。如果您的应用程序不适合该模型，则您必须在其中包含特定于该应用程序的内容。如果您以 \xe2\x80\x9cgeneric\xe2\x80\x9d 的方式执行此操作，您将下载通用客户端应用程序应该执行的操作的复杂描述，并且该描述本身会开始感觉越来越多就像编程语言一样。现在你又回到了第一个方向，除了混合了一种（可能设计得很糟糕的）新的特定于领域的语言。您不妨开门见山，承认完全通用是不值得的。

\n\n

但这并不是说您不应该仔细考虑您公开的资源、适用于这些操作的动词以及用户的软件将如何发现这些资源。遵循 REST 和 HATEOAS 将会有很大帮助（如果您清楚地了解应用程序的底层抽象模型是什么，这会有所帮助；您应该致力于以自然的方式公开它）。

\n