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

查看:98
本文介绍了我应该为GWT应用程序构建一个REST后端吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在计划一个新的应用程序,并一直在尝试将GWT作为可能的前端。我正面临的设计问题是这样的。



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



选项B:使用Spring MVC 3.0和所有优秀的@Controller,@Service和@Repository注释构建一个REST后端,并使用GWT覆盖功能和GWT构建一个客户端库来与后端对话请求生成器?



我对这种类型的设计的所有优缺点和用户体验感兴趣吗?

解决方案

问自己这个问题:我需要重用服务器端接口与非GWT前端吗?



如果答案是否,我只需要一个GWT客户端:您可以使用GWT-RPC并利用可以在服务器端和客户端都使用Java对象。这也可以使通信更有效率,至少当与<继承name =com.google.gwt.user.RemoteServiceObfuscateTypeNames/> 时一起使用时将类型名称缩短为小数字值。如果答案是是的,我会做我的服务可用于多种前端:您可以将REST与JSON(或XML)一起使用,非GWT客户端也可以理解它。除了切换客户端之外,这还允许您更轻松地切换到其他服务器实现(可能是非Java)。缺点是,您可能必须编写包装器( JavaScript Overlay Types )或转换代码在GWT客户端从JSON对象中构建好的Java对象。当您部署新版本的服务时,您必须特别小心,这会使我们回到缺乏类型安全性的问题。



第三个选项当然是要建立两个。如果公共REST接口不同于GWT-RPC接口,我会选择这个选项 - 也许只提供一些易于使用的服务。


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?

解决方案

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.

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

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆