9

我正在开发一个通过 Web 服务与（Java）后端通信的富互联网 Web 应用程序。我在 Flex/Flash 和 GWT/Javascript 中都对用户界面进行了原型设计，并注意到这些 RIA 平台倾向于支持 RPC 样式的后端通信方法（AMF 用于 Flex，GWT-RPC 用于 GWT）。

就我而言，服务器还需要为我未编写的其他客户端提供 Web 服务。因此，我倾向于基于标准的 Web 服务（例如 SOAP 和 REST）。我相信 RIA 必须使用我们为其他人提供的相同网络服务。我“得到”了 SOAP，因为它模拟了我从经验中熟悉的 RPC 样式。我是 REST 新手，但使用 CXF/Jackson 对 REST 后端进行了原型设计。然而，此时我的 REST API 仍然感觉像是一个 RPC 样式的 API，我意识到这是因为我无法理解 HATEOAS 的想法。

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

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

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

ps - 还有两个细节——这个应用程序有一个极其复杂的、深度嵌套的数据模型。此外，如果有人告诉我我们不是 100% 纯 REST Web 应用程序，我也不会在意。

4

2 回答 2

3

鉴于 GWT 应用程序由 HTTP 提供服务，将其与服务器紧密耦合并不违反 HATEOAS。它是“按需代码”。

Google、Twitter 和 Facebook 都为其应用程序使用特定的 API，与向第三方公开的 API 不同（Twitter 最近已将其公共 API 用于其 Web 应用程序，但最初并非如此）。谷歌表示他们没有计划将 G+ 转移到其公共 API，因为它允许他们在不破坏第三方的情况下进行试验和做出重大更改。

于 2012-01-09T22:29:19.623 回答
3

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

让我再解释一下。虽然可以设想一个完全通用的应用程序接口，它只是以人类可用的方式公开模型，但实际上编写这样一个软件非常困难，除了真正微小的领域（例如，填写将用于填充一个数据库，其中所有字段都是从有限的简单枚举中挑选出来的）。如果您的应用程序不适合那个模型，你必须有一些特定于应用程序的东西。如果您以“通用”方式执行此操作，您将下载通用客户端应用程序应该做什么的复杂描述，并且该描述本身将开始感觉越来越像一种编程语言。现在你又回到了原点，除了混合中的（可能设计糟糕的）新的特定领域语言。你不妨切入正题，接受完全通用的做法是不值得的。

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

于 2012-01-09T22:37:41.857 回答