I like the idea of: "truly restful API for all Google Services (i.e. Cloud SQL, Datastorage, etc)" That would be great!
On the other side, it seems Google has plans to make RequestFactory a thing of past. That's the reason, in new GPE version, you won't even see the option of "App Engine Connected Android App" which was a sample app (two apps rather: Android client and server) providing RF example. Moreover, the RF validation tool really sucked big time. It took me 4 days to actually make it run. It only ran on Helios for me; when I was trying it on Indigo... jeezzzz!!! Does anybody know how to get the "App Engine Connected Android App" option on the new GPE? I want to continue using RF till they open the Endpoints publicly. Thanks, Raj On Tue, Jul 10, 2012 at 7:56 PM, Ümit Seren <uemit.se...@gmail.com> wrote: > I think Cloud Endpoints are bigger than RequestFactory for GWT. > They are supposed to be a truly restful API for all Google Services (i.e. > Cloud SQL, Datastorage, etc). > However RequestFactory has some distinct features that AFAIK Clound > Endpoints don't support yet (i.e. tracking changes and transmitting only > delta's, batching, specifying the object graph that goes over the wire). > I think it really depends on your use case and type of project. If you are > doing a lot of CRUD (i.e. business application) and only access your > backend via GWT then RequestFactory might be the better fit. However if you > need to access your backend from different clients and also allow maybe a > computer readable knowledge approach than Cloud Endpoints might be the > better choice. > > > On Sunday, July 8, 2012 4:31:48 PM UTC+2, AB wrote: >> >> I signed up for the trusted tester some 3 days back and yet to get it. >> Do you guys know how long it took for you to get it, if anybody got it. >> >> You can call me noob but from what I understood from the IO video, Cloud >> endpoint seem to replace the request factory approach. You don't need to >> use any request factory anywhere for the cloud endpoint based approach. >> Correct me if I'm wrong. >> >> please let me know. >> >> Thanks much, >> Raj... >> >> >> On Sun, Jul 8, 2012 at 2:00 PM, Thomas Broyer <t.bro...@gmail.com> wrote: >> >>> >>> On Saturday, July 7, 2012 6:11:51 PM UTC+2, Nick Siderakis wrote: >>>> >>>> http://www.youtube.com/watch?**v**=v9TG7OzsZqQ&feature=player_**de** >>>> tailpage#t=910s<http://www.youtube.com/watch?v=v9TG7OzsZqQ&feature=player_detailpage#t=910s> >>>> >>>> It looks like the new Cloud Endpoints implement a lot of >>>> the functionality that makes RequestFactory attractive. >>>> >>>> - Patch commits - only send what has changed to the server. >>>> - Batch requests - RequestBatcher >>>> - Partial GETs - similar to defining a proxy with a subset of >>>> attributes. >>>> >>>> It has the benefit of being a standard REST api, but is limited to App >>>> Engine Apps. >>>> >>>> What do you guys think? >>>> >>> >>> Looks really great! >>> I knew they'd been working hard for the past years to build a common >>> framework for all their APIs, in a truely RESTful way, with discoverability >>> (hopefully HATEOAS too, though I haven't checked), etc. (Joe Gregorio, who >>> worked on the Atom Publication Protocol some years ago, as Google adopted >>> it for the GData APIs, but before Joe joined Google, is part of this >>> ongoing effort AFAIK) ; what I didn't see coming was to allow external >>> developers to leverage that framework to build their own APIs! >>> It'd be too bad if it were limited to AppEngine and stayed closed source >>> though… >>> >>> Bob Vawter (who created RequestFactory along with Ray Ryan), created >>> Flatpack in his new job, which uses a very similar approach to Cloud >>> Endpoints, though leveraging JAX-RS on the server-side. >>> See >>> https://plus.google.com/**110742163942000381699/posts/**BRyL2DFy6hk<https://plus.google.com/110742163942000381699/posts/BRyL2DFy6hk> >>> and https://plus.**google.com/**110742163942000381699/posts/** >>> NxRfQjatF6g<https://plus.google.com/110742163942000381699/posts/NxRfQjatF6g> >>> Now is this really "what RF should have been", as he wrote it, I'm not >>> sure. But Flatpack doesn't (yet) has dirty-tracking. >>> >>> BTW, does Cloud Endpoint client-side APIs have dirty-tracking? or you >>> have to do it yourself and build "patch commits" by hand? >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Google Web Toolkit" group. >>> To view this discussion on the web visit https://groups.google.com/d/** >>> msg/google-web-toolkit/-/xlw-**9foMFuQJ<https://groups.google.com/d/msg/google-web-toolkit/-/xlw-9foMFuQJ> >>> . >>> >>> To post to this group, send email to google-web-toolkit@** >>> googlegroups.com <google-web-toolkit@googlegroups.com>. >>> To unsubscribe from this group, send email to google-web-toolkit+** >>> unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> >>> . >>> For more options, visit this group at http://groups.google.com/** >>> group/google-web-toolkit?hl=en<http://groups.google.com/group/google-web-toolkit?hl=en> >>> **. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-web-toolkit/-/4esf56Y8QPEJ. > > To post to this group, send email to google-web-toolkit@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
