我们的团队正在开发App Engine后端的Android应用程序。我们在实现客户端-服务器通信的观点上有一些分歧。一方面，App Engine建议使用RequestFactory方法，例如Google所说的
和light-weighed
但是我们发现这种方法有点“笨拙”。另一方面，我们可以使用一种众所周知的普通servlet方法，并且感觉更舒适。我们肯定希望较轻，更快和可扩展通信，但是RequestFactory真正以什么比例提供它们？从这两种方法中我们还能获得和摆脱的还有更多。
[更多内容，我们了解了诸如GWT-RPC(RequestFactory的较旧版本)和RestyGWT之类的选项。但是我们对这些方法知之甚少，也不确定它们是否适合我们的情况。]
我在这里发现了一些未回答的类似问题。所以我想，这对许多人来说可能是一个有用的讨论。
一些注意事项:
RequestFactory不是AppEngine的一部分(请参阅here)，而是最新的Android Eclipse插件引入的附加组件。最初，RequestFactory是为GWT创建的。 RequestFactory的优点是可以与GWT和Android无缝地协同工作。 缺点是它不是跨平台的，即不适用于iPhone等。尚不清楚如何对RequestFactory进行版本控制。如果您的应用程序很大且在不断发展，那么您肯定有两个或多个版本的RPC API服务于客户端。 GWT客户端很容易被迫使用最新的API(=页面重新加载)，而Android则不然。 AFAIK，没有两个RequestFactory端点的选项。使用REST，您可以简单地拥有用于不同API版本的多个URL。 混合使用公共(public)/专用API。由于没有多个RequestFactory端点，因此您不能轻易将它们分为公共(public)(不需要身份验证)和私有(private)/安全(=需要身份验证)。使用REST(和GWT-RPC)，您可以简单地拥有两个servlet(私有(private)和公共(public))，并在web.xml中设置安全性约束(或拥有自己的servlet过滤器)。 RequestFactory不支持java.util.Map。这严重限制了您拥有具有动态属性的实体的能力-有一些解决方法，但是它们是IMO不必要的麻烦(例如具有两个列表，一个用于键，另一个用于值)。
解决方案:这是我在项目中使用的解决方案:
创建一个返回POJO域对象的服务层。 创建调用服务层的RPC层。您可以有多种RPC技术调用同一服务层。我通常有GWT-RPC和REST。 有时不可能使用仅POJO的域对象(同样由于JPA/JDO)，因此迫使您创建DTO。 DTO很难维护，如果可能，我会尽量避免使用它们。可以在大多数情况下使用域对象并采取一些解决方法:在AppEngine上，您可以使用Objectify而不是低级/JPA/JDO来获得大量帮助。它supports GWT-RPC。对于REST，我建议您在can do all kinds of custom conversions处使用Jackson。