Our team is working on Android Application back ended with App Engine. We have some difference on opinions regarding the implementation of client-server communication. On one hand App Engine suggesting RequestFactory approach, which (as Google say)
provides a solid foundation for automatic batching and caching of requests in the future
and light-weighed
But we find this approach a little "clumsy". On the other hand we can use an ordinary servlet approach which we know well, and feel more comfortable with. We sure want lighter, faster and scalable communication, but in what proportion RequestFactory really provides them? What more we can gain and loose from both approaches.
[More of that, we read about such options like GWT-RPC (an older version of RequestFactory), and RestyGWT. But we know little about these approaches and not sure if their fit our case.]
I found here some similar questions not answered. So I suppose, this may be a helpful discussion for many.
A few notes:
RequestFactory is not a part of AppEngine (see here), but an add-on introduced by the latest Android Eclipse plugin. Originally RequestFactory was created for GWT.
The upside of RequestFactory is that is seamlessly works with GWT and Android.
The downside is that it's not cross-platform, i.e. not available for iPhone, etc..
It's unclear how to version RequestFactory. If your app is big and evolving, you are bound to have two or more versions of RPC APIs serving clients. GWT clients can be easily forced to use the newest API (=page reload), not so with Android. AFAIK, there is no option of having two RequestFactory endpoints. With REST you can simply have multiple URLs for different API versions.
Mixing public/private APIs. Since there are no multiple RequestFactory endpoints you can not easily divide them into public (no auth required) and private/secure (= auth required). With REST (and GWT-RPC) you can simply have two servlets (private and public) and set security constraints in web.xml (or have your own servlet Filter).
RequestFactory does not support java.util.Map. This severely limits you ability to have entities with dynamic properties - there are workarounds to this but they are IMO an unnecessary kludge (like having two lists, one for keys the other for values).
Solution: this is a solution that I use in my projects:
Create a service layer that returns POJO domain objects.
Create RPC layer that calls the service layer. You can have multiple RPC technologies calling the same service layer. I usually have GWT-RPC and REST.
Using POJO-only domain objects is sometimes impossible (also due to JPA/JDO), thus forcing you to create DTOs. DTOs are a pain to maintain and I try to avoid them if possible. It's possible to use domain objects most of the time with some workarounds: on AppEngine you can get a lot of help by using Objectify instead of low-level/JPA/JDO. It supports GWT-RPC. With REST I suggest you use Jackson where you can do all kinds of custom conversions.