问我应该为GWT应用程序构建REST后端吗

EN

问自己这个问题：“我需要用非GWT前端重用服务器端接口吗？”

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

如果答案是“是的，我将使我的服务可供多种类型的前端访问”：您可以将REST与JSON (或XML)一起使用，这也可以被非GWT客户机理解。除了切换客户机之外，这还允许您在将来更容易地切换到不同的服务器实现(可能不是Java)。缺点是，您可能必须在GWT客户端编写包装器(JavaScript Overlay Types)或转换代码，以便从JSON对象构建良好的Java对象。在部署服务的新版本时，您必须格外小心，这又将我们带回到缺乏类型安全的问题上。

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

如果use还使用RestyGWT项目，则可以同时使用这两种方法。它将使调用基于REST的JSON资源与使用GWT-RPC一样简单。此外，您通常可以在客户端重用来自服务器端的相同请求响应DTO。

我们在创建Spiffy UI Framework时遇到了同样的问题。我们选择了休息，我再也不会回去了。我甚至可以说GWT-RPC是一个GWT Anti-pattern。

即使您从未打算公开您的REST端点，REST也是一个好主意。创建REST API将使您的UI更快，API更好，整个应用程序更易于维护。