我应该为 GWT 应用程序构建 REST 后端吗 [英] Should I build a REST backend for GWT application

问题描述

我正在计划一个新的应用程序，并且一直在尝试将 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.

我应该使用选项 A:GWT-RPC 并快速构建应用程序

Should I use Option A: GWT-RPC and build the app quickly

选项 B:使用 Spring MVC 3.0 和所有出色的 @Controller、@Service、@Repository 注释构建 REST 后端，并使用 GWT 覆盖功能和 GWT 请求构建器构建客户端库以与后端通信?

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?

推荐答案

问自己这个问题:我是否需要在非 GWT 前端重用服务器端接口?"

Ask yourself the question: "Will I need to reuse the server-side interface with a non-GWT front-end?"

如果答案是不，我只有一个 GWT 客户端":您可以使用 GWT-RPC，并利用您可以在服务器端和客户端.这也可以使通信更加高效，至少在与 <inherits name="com.google.gwt.user.RemoteServiceObfuscateTypeNames"/> 一起使用时，将类型名称缩短为小数值.您还将获得更好的错误处理(使用异常)、类型安全等优势.

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.

如果答案是是的，我会让我的服务可供多种前端访问":您可以将 REST 与 JSON(或 XML)一起使用，这也可以理解为非 GWT 客户端.除了切换客户端之外，这还允许您将来更轻松地切换到不同的服务器实现(可能是非 Java).缺点是，您可能必须编写包装器(JavaScript 覆盖类型)或转换GWT 客户端上的代码以从 JSON 对象构建漂亮的 Java 对象.在部署新版本的服务时，您必须特别小心，这让我们又回到了缺乏类型安全的问题上.

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.

当然，第三种选择是同时构建两者.如果公共 REST 接口无论如何都应该与 GWT-RPC 接口不同，我会选择这个选项 - 也许只是提供易于使用的服务的一个子集.

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.

这篇关于我应该为 GWT 应用程序构建 REST 后端吗的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！