GWT 富互联网应用程序 (RIA) 和 REST HATEOAS - 它们的兼容性如何？
我正在开发一个富互联网 Web 应用程序，该应用程序通过 Web 服务与（Java）后端进行通信。我已经用 Flex/Flash 和 GWT/Javascript 制作了用户界面原型，并注意到这些 RIA 平台倾向于采用 RPC 风格的后端通信方法（Flex 为 AMF，GWT 为 GWT-RPC）。
就我而言，服务器还需要向其他客户端提供 Web 服务，而这些客户端并非由我编写。因此，我倾向于基于标准的 Web 服务（例如 SOAP 和 REST）。我确信 RIA 必须使用我们为其他人提供的相同网络服务。我“理解”了 SOAP，因为它模拟了我从经验中熟悉的 RPC 风格。我是 REST 新手，但已经使用 CXF/Jackson 制作了 REST 后端原型。然而，此时我的 REST API 仍然感觉像 RPC 风格的 API，我意识到这是因为我无法理解 HATEOAS 的想法。
我已阅读Roy T. Fieldings 有用的博客文章 大约 10 次，我想我开始看到曙光了。例如，我很清楚，如果我将各种状态转换的链接与我的资源一起包含在内，我确实可以减少客户端和服务器之间的耦合量。我的客户端可以只渲染按钮，使用户能够访问当时可以在显示的实体上执行的合法操作。
但是 RIA 与其服务器应用程序之间的松散耦合重要吗？
就其本质而言，RIA 与服务器数据模型紧密耦合。他们开箱即用地预设了许多事情。我猜这就是为什么他们也更喜欢 RPC 风格的应用程序协议......因为松散耦合不是设计目标。但我开始意识到，如果我们认真对待 HATEOAS，我们可以编写一个更通用的 RIA 客户端，该客户端将对数据模型和可以执行的操作做出很少的假设。这可以减少通过更改后端来维护客户端的工作量，但这有意义吗？收益是否大于成本？
ps - 还有两个细节 - 该应用程序具有极其复杂、深度嵌套的数据模型。另外，如果有人告诉我我们不是 100% 纯 REST Web 应用程序，我也不在乎。
I am in the process of developing a rich internet web application that communicates to a (Java) back-end via web services. I have prototyped a user interface in both Flex/Flash and GWT/Javascript and have noticed that these RIA platforms tend to favor an RPC-style method of back-end communication (AMF for Flex and GWT-RPC for GWT).
In my case, the server also needs to provide web services other clients that I do not author. Because of this, I am leaning towards standards-based web services (e.g. SOAP and REST). I am convinced that the RIA must use the same web service we provide for others. I "get" SOAP because it models the RPC style I am familiar with from experience. I am new to REST, but have prototyped a REST back-end using CXF/Jackson. At this time, however, my REST API still feels like an RPC-style API and I realize it's because I am having trouble getting my head around the idea of HATEOAS.
I have read Roy T. Fieldings helpful blog post about 10 times and I think I am beginning to see the light. For example, it is clear to me that if I were to include links to various state transitions along with my resource I could really reduce the amount of coupling between my client and server. My client could just render buttons that provide the user with access to the legal operations that can be performed on the displayed entity at that time.
But does loose coupling between a RIA and its server application matter?
By their very nature, RIAs are pretty tightly coupled with the server data model. Out of the box they presuppose many things. I am guessing that is why they also prefer an RPC-style application protocol...because loose coupling is not a design goal. But I am beginning to realize that if we took HATEOAS seriously, we could write a much more generic RIA client that would make VERY few assumptions about the data model and operations that can be performed. That could reduce the amount of effort to maintain the client through changes in the back-end, but does this make sense? does the benefit outweigh the cost?
p.s. - Two more details -- This application has an extremely complex, deeply nested data model. Also, I could not care less if somebody tells me we are not a 100% pure REST web-app.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是一个很棒的哲学问题。我的一般回应是应该预期会有一些耦合。
让我解释一下。虽然可以设想一个完全通用的应用程序接口，仅以人类可用的方式公开模型，但实际上编写这样的软件非常困难，除了真正微小的领域（例如，填充将用于填充数据库，其中所有字段都是从有限的简单枚举中选取的）。如果您的应用程序不适合该模型，则您必须在其中包含特定于该应用程序的内容。如果您以“通用”方式执行此操作，您将下载通用客户端应用程序应该执行的操作的复杂描述，并且该描述本身将开始越来越像一种编程语言。现在你又回到了第一个方向，除了混合了一种（可能设计得很糟糕的）新的特定于领域的语言。您不妨开门见山，承认完全通用是不值得的。
但这并不是说您不应该仔细考虑您公开的资源、适用于这些操作的动词以及用户的软件将如何发现这些资源。遵循 REST 和 HATEOAS 将会有很大帮助（如果您清楚地了解应用程序的底层抽象模型是什么，这会有所帮助；您应该致力于以自然的方式公开它）。
It's an excellent philosophical question. My general response is some coupling should be expected.
Let me explain more. While it's possible to conceive of a fully generic application interface that just exposes the model in a human-usable way, it's actually incredibly difficult to write such a piece of software except for truly miniscule domains (e.g., filling a record that will be used to populate a DB where all the fields are picked from finite simple enumerations). If your application doesn't fit that model, you're going to have to have something in there that is specific to the app. If you do that in a “generic” way, you'll be downloading a complex description of what your generic client app is supposed to do, and that description will itself start to feel more and more like a programming language. Now you're back to square one, except with a (probably badly-designed) new domain-specific language in the mix as well. You might as well cut to the chase and accept that going wholly generic isn't worthwhile.
But that's not to say that you shouldn't take care to think carefully about what resources you expose, what verbs apply to those operations, and how users' software will discover those resources. Following REST and HATEOAS there will help a lot (and it helps if you've got a clear idea about what the application's underlying abstract model is; you should aim to expose that in a natural way).
鉴于 GWT 应用程序由 HTTP 提供服务，使其与服务器紧密耦合并不违反 HATEOAS。这就是“按需编码”。
Google、Twitter 和 Facebook 都在其应用程序中使用特定的 API，这与向第三方公开的 API 不同（Twitter 最近开始在其网络应用程序中使用其公共 API，但最初并非如此）。谷歌表示，他们没有计划将 G+ 转移到其公共 API，因为它允许他们在不破坏第三方的情况下进行试验和做出重大更改。
Given that the GWT app is served by HTTP, having it tightly coupled with the server is not violating HATEOAS. It's" code on demand".
Google, Twitter and Facebook all use specific APIs for their app, different from the one exposed to third parties (Twitter has recently moved to using their public API for their web app, but it wasn't originally the case). Google said they had no plan to move G+ over to its public API, because it allows them to experiment and make breaking changes without breaking third parties.