我应该为 GWT 应用程序构建 REST 后端吗
我正在计划一个新的应用程序，并一直在尝试使用 GWT 作为可能的前端。我面临的设计问题是这样的。
我应该使用 选项 A：GWT-RPC 并快速构建应用程序
选项 B：使用 Spring MVC 3.0 以及所有出色的 @Controller、@Service、@Repository 注释构建 REST 后端，并构建客户端库以使用 GWT 覆盖与后端对话功能和 GWT 请求构建器？
我对这种设计的所有优点、缺点以及人们的体验感兴趣？
I am planning a new application and have been experimenting with GWT as a possible frontend. The design question I am facing is this.
Should I use
Option A: GWT-RPC and build the app quickly
Option B: Build a REST backend using Spring MVC 3.0 with all the great @Controller, @Service, @Repository annotations and build a client side library to talk to the backend using the GWT overlay features and the GWT Request builder?
I am interested in all the pros and cons and people experiences with this type of design?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
问自己这样一个问题：“我需要在非 GWT 前端中重用服务器端接口吗？”
如果答案是“不，我只要一个 GWT 客户端”：您可以使用 GWT-RPC，并利用这样一个事实：您可以在服务器和客户端上使用 Java 对象。客户端。这还可以使通信更加高效，至少在与
如果答案是“是的，我将使我的服务可供多种前端访问” ：您可以将 REST 与 JSON（或 XML）结合使用，非 GWT 客户端也可以理解。除了切换客户端之外，这还允许您将来更轻松地切换到不同的服务器实现（可能是非 Java）。缺点是，您可能必须编写包装器（JavaScript Overlay Types）或转换GWT 客户端上的代码用于从 JSON 对象构建漂亮的 Java 对象。当您部署新版本的服务时，您必须特别小心，这让我们回到了缺乏类型安全的问题。
第三种选择当然是同时构建两者。如果公共 REST 接口无论如何都应该与 GWT-RPC 接口不同，我会选择此选项 - 也许只提供易于使用的服务的子集。
Ask yourself the question: "Will I need to reuse the server-side interface with a non-GWT front-end?"
If the answer is "no, I'll just have a GWT client": You can use GWT-RPC, and take advantage of the fact that you can use your Java objects both on the server and the client-side. This can also make the communication a bit more efficient, at least when used with
<inherits name="com.google.gwt.user.RemoteServiceObfuscateTypeNames" />, which shortens the type names to small numeric values. You'll also get the advantage of better error handling (using Exceptions), type safety, etc.If the answer is "yes, I'll make my service accessible for multiple kinds of front-ends": You can use REST with JSON (or XML), which can also be understood by non-GWT clients. In addition to switching clients, this would also allow you to switch to a different server implementation (maybe non-Java) in the future more easily. The disadvantage is, that you'll probably have to write wrappers (JavaScript Overlay Types) or transformation code on the GWT client side to build nice Java objects from the JSON objects. You'll have to be especially careful when you deploy a new version of the service, which brings us back to the lack of type safety.
The third option of course would be to build both. I'd choose this option, if the public REST interface should be different from the GWT-RPC interface anyway - maybe providing just a subset of easy to use services.
如果还使用 RestyGWT 项目，您可以同时执行这两项操作。它将使得调用基于 REST 的 JSON 资源就像使用 GWT-RPC 一样简单。另外，您通常可以在客户端重用来自服务器端的相同请求响应 DTO。
You can do both if use also use the RestyGWT project. It will make calling REST based JSON resources as easy as using GWT-RPC. Plus you can typically reuse the same request response DTOs from the server side on the client side.
当我们创建 Spiffy UI 框架 时，我们遇到了同样的问题。我们选择休息，我永远不会回去。我什至会说 GWT-RPC 是一种 GWT 反模式。
即使您从未打算公开 REST 端点，REST 也是一个好主意。创建 REST API 将使您的 UI 更快、API 更好、整个应用程序更易于维护。
We ran into the same issue when we created the Spiffy UI Framework. We chose REST and I would never go back. I'd even say GWT-RPC is a GWT Anti-pattern.
REST is a good idea even if you never intend to expose your REST endpoints. Creating a REST API will make your UI faster, your API better, and your entire application more maintainable.
我会说构建一个 REST 后端。在我的上一个项目中，我们在最初几个月开始使用 GWT-RPC 进行开发，我们想要快速引导。后来，当我们需要 REST API 时，重构的成本非常高，我们最终得到了两个后端 API（REST 和 RPC）。
如果您构建一个适当的 REST 后端，并在客户端构建一个反序列化基础设施（以转换json\xml 到 GWT Java 对象），那么 RPC 的好处几乎为零。
REST 方法的另一个有时被遗忘的优点是，它对于运行客户端的浏览器来说更自然，RPC 是一种调解协议，其中所有请求都使用 POST。以标准方式读取资源时，您可以从客户端缓存中受益。
回答艾迈斯半导体评论：
关于RPC协议，上次我用firebug“嗅探”它时它看起来不像json，所以我不知道。不过，即使它是基于 json 的，它仍然只使用 HTTP POST 方法与服务器通信，所以我在这里关于缓存的观点仍然有效，浏览器不会缓存 POST 请求。
考虑到回顾以及哪些方面可以做得更好，在面向资源的架构中编写 RPC 服务可能会导致以后更容易移植到 REST。请记住，在 REST 中，通常会通过基本 CRUD 操作公开资源，如果您在编写 RPC 服务时专注于该方法，那么您应该没问题。
I would say build a REST backend. In my last project we started by developing using GWT-RPC for the first few months, we wanted fast bootstrapping. Later on, when we needed the REST API, it was so expensive to do the refactoring we ended up with two backend APIs (REST and RPC)
If you build a proper REST backend, and a deserialization infra on the client side (to transform the json\xml to GWT Java objects) then the benefit of the RPC is almost nothing.
Another sometimes forgotten advantage of the REST approach is that it's more natural to the browser running the client, RPC is a propitiatory protocol, where all the requests are using POST. You can benefit from client side caching when reading resources in the standard way.
Answering ams comments:
Regarding the RPC protocol, last time I "sniffed" it using firebug it didn't look like json, so I don't know about that. Though, even if it is json based, it still uses only the HTTP POST method to communicate with the server, so my point here about caching is still valid, the browser won't cache POST requests.
Regarding the retrospective and what could have done better, writing the RPC service in a resource oriented architecture could lead later to easier porting to REST. remember that in REST one usually exposes resources with the basic CRUD operations, if you focus on that approach when writing the RPC service then you should be fine.
REST 架构风格促进可检查消息（有助于调试和安全）、API 演变、多平台、简单接口、故障恢复、高可扩展性以及（可选）通过按需代码可扩展的系统。它以每次交互的性能来换取整体网络效率。它减少了服务器对一致应用程序行为的控制。
“RPC 风格”（我们所说的与 REST 相对）促进了平台统一性、接口可变性、代码生成（从而能够假装网络不存在，但请参阅 谬论），以及自定义交互。它以整体网络效率换取高每次交互性能。它增强了服务器对一致应用程序行为的控制。
如果您的应用程序需要前一种品质，请使用 REST 风格。如果需要后者，请使用 RPC 风格。
The REST architectural style promotes inspectable messages (which aids debugging and security), API evolution, multiple platforms, simple interfaces, failure recovery, high scalability, and (optionally) extensible systems via code on demand. It trades per-interaction performance for overall network efficiency. It reduces the server's control over consistent application behavior.
The "RPC style" (as we speak of it in opposition to REST) promotes platform uniformity, interface variability, code generation (and thereby the ability to pretend the network doesn't exist, but see the Fallacies), and customized interactions. It trades overall network efficiency for high per-interaction performance. It increases the server's control over consistent application behavior.
If your application desires the former qualities, use the REST style. If it desires the latter, use the RPC style.
如果您计划在服务器端使用 Hibernate/JPA 并将包含关系数据的结果 POJO 发送到客户端（即带有电话集合的 Employee 对象），那么一定要使用 REST 实现。
一个月前，我使用 GWT RPC 开始了我的 GWT 项目。一切都很顺利，直到我尝试从底层数据库中序列化一个具有一对多关系的对象。并得到了可怕的：
如果你遇到这种情况并且想继续使用 GWT RPC，你将不得不使用类似的东西：
我现在使用 RestyGWT。切换相当轻松，我的 POJO 的序列化也没有问题。
If you're planning on using using Hibernate/JPA on the server-side and sending the resulting POJO's with relational data in them to the client (ie. an Employee object with a collection of Phones), definitely go with the REST implementation.
I started my GWT project a month ago using GWT RPC. All was well until I tried to serialize an object from the underlying db with a One-To-Many relationship in it. And got the dreaded:
If you encounter this and want to stay with GWT RPC you will have to use something like:
I'm now using RestyGWT. The switch was fairly painless and my POJO's serialize without issue.
我想说这取决于您的总体应用范围。如果您的后端应该被其他客户端使用，需要可扩展等，那么使用 REST 创建一个单独的模块。如果后端仅由该客户端使用，则选择 GWT-RPC 解决方案。
I would say that this depends on the scope of your total application. If your backend should be used by other clients, needs to be extendable etc. then create a separate module using REST. If the backend is to be used by only this client, then go for the GWT-RPC solution.