我正在开发一个通过Web服务与（Java）后端通信的富Internet网络应用程序。我已经在Flex / Flash和GWT / Javascript中构建了一个用户界面原型，并注意到这些RIA平台倾向于采用RPC风格的后端通信方法（AMF for Flex和GWT-RPC for GWT）。
在我的情况下，服务器还需要提供我没有创作的其他客户端的Web服务。因此，我倾向于基于标准的Web服务（例如SOAP和REST）。我确信RIA必须使用我们为其他人提供的相同Web服务。我“得到”SOAP因为它根据经验建模我熟悉的RPC样式。我是REST新手，但使用CXF / Jackson制作了一个REST后端原型。然而，在这个时候，我的REST API仍然感觉就像一个RPC风格的API，我意识到这是因为我无法理解HATEOAS的想法。
我已经阅读了Roy T. Fieldings helpful blog post大约10次，我想我开始看到光明了。例如，我很清楚，如果我要包含各种状态转换的链接以及我的资源，我可以真正减少客户端和服务器之间的耦合量。我的客户端可以只渲染按钮，使用户可以访问当时可以在显示的实体上执行的合法操作。
但RIA与其服务器应用之间的松散耦合是否重要？
就其本质而言，RIA与服务器数据模型紧密结合。开箱即用，他们预先假定许多事情。我猜这就是为什么他们也更喜欢RPC风格的应用程序协议...因为松耦合不是设计目标。但我开始意识到，如果我们认真对待HATEOAS，我们可以编写一个更通用的RIA客户端，它会对可以执行的数据模型和操作做出非常少的假设。这可以减少通过后端更改来维护客户端的努力量，但这是否有意义？收益是否超过成本？
P.S。 - 另外两个细节 - 此应用程序具有极其复杂，深度嵌套的数据模型。另外，如果有人告诉我，我们不是一个100％纯粹的REST网络应用程序，我也不在乎。
答案 0 :(得分：3)
鉴于GWT应用程序由HTTP提供服务，与服务器紧密耦合并不违反HATEOAS。它是“按需代码”。
谷歌，Twitter和Facebook都为他们的应用程序使用特定的API，不同于暴露给第三方的应用程序（Twitter最近开始使用他们的公共API用于他们的Web应用程序，但最初并非如此）。谷歌表示，他们没有计划将G +转移到其公共API，因为它允许他们在不破坏第三方的情况下进行实验并进行重大改变。答案 1 :(得分：3)
这是一个很好的哲学问题。我的一般反应是应该预期某种耦合。
让我解释一下。虽然可以设想一个完全通用的应用程序界面，只是以人类可用的方式暴露模型，但实际上编写这样一个软件实际上非常困难，除了真正微不足道的域名（例如，填写将用于填充数据库，其中所有字段都是从有限的简单枚举中选取的。如果您的应用程序不适合该模型，那么您将不得不在其中拥有特定于该应用程序的内容。如果你以“通用”的方式做到这一点，你将下载一个复杂的描述你的通用客户端应用程序应该做什么，并且该描述本身将开始感觉越来越像一种编程语言。现在你又回到了原点，除了混合中也有一个（可能设计得很糟糕的）新的特定领域语言。你不妨切入追逐，并接受完全通用是不值得的。
但这并不是说您不应该仔细考虑您所公开的资源，哪些动词适用于这些操作，以及用户软件将如何发现这些资源。在REST和HATEOAS之后会有很多帮助（如果你对应用程序的底层抽象模型有一个清晰的认识，它会有所帮助;你应该以自然的方式公开它）。