On Sep 17, 5:37 am, Thomas Broyer <[EMAIL PROTECTED]> wrote:
> On 16 sep, 18:14, walden <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > Thomas,
>
> > On Sep 16, 11:10 am, Thomas Broyer <[EMAIL PROTECTED]> wrote:
>
> > > (I you ask me my opinion: GWT-RPC is not RESTful so I don't use it,
> > > but the hability to share a class between client and server code is
> > > appealing; I'm not using such a thing either though)
>
> > How do you arrive at that opinion?
>
> > You can use or not use GWT RPC for whatever reason you like. But when
> > you say you don't use GWT RPC because it's not RESTful, I think that
> > carries no real meaning other than general FUD. It would be better to
> > state the specific tradeoffs that don't work for you. I'm just
> > concerned that some might avoid a very useful technology for a very
> > questionable reason. Can you please shed some more light?
>
> 1. RPC: the "method" is in the request body, not as an HTTP method
> (not always possible though).
What is the design tradeoff though? Why does a pragmatic developer
care?
> 2. If I want a "collection resource" (GETting the resource returns me
> a representation of the "list") and individual "entry resources" (that
> I could GET, PUT and DELETE –using "method override" in older Safari–,
> and eventually POST for other needs...), I need 2 RemoteService
> classes, and then using the "EntryService" means changing the "service
> location" before each method call; this is not the way GWT-RPC has
> been thought, GWT-RPC isn't "resource-oriented", it's, well, RPC...
I can't really understand any of that. What do you need to do that
REST gives you and GWT RPC fails?
> 3. POST for everything, even for things that should have been GETs,
> PUTs or DELETEs; this makes HTTP caches unusable (which you might
> want, but not necessarily).
> etc.
PUTS and DELETES are not required by REST. As for POST versus GET for
inquiries, even within REST there are tradeoffs and minor misfits.
You may use a POST form when you have a lot of parameters, even though
your intention is to invoke a "safe" method, which POST does not give
you by HTTP contract.
>
> In brief: GWT-RPC is RPC (method calls), it's not "resource-oriented".
> It "tunnels" within HTTP requests, but it isn't HTTP. Well, it's the
> same as SOAP, without the bloated XML serialization and minus the
> extensibility.
These answers are bsically REST religion. Assuming I have no
religion, why do I care?
>
> GWT-RPC is good for prototyping, because it's easy to set up; but it
> isn't "web-style", so it won't scale as well as "RESTful web
> services" (a book that I highly recommend, along with blog posts from
> Joe Gregorio).
On the face of it, I disagree that it won't scale. I would like to
have a scenario.
> I guess generators could be used to make RESTful web services as easy
> as GWT-RPC (I didn't investigate yet, as our server-side language
> is... JavaScript!)- Hide quoted text -
GWT RPC has to be considered as part of the optional COD variant of
REST. In a nutshell, interactions between a GWT client and server are
private interactions between components which are not expected to
independently co-evolve. The scaleability is one level up, where the
GWT host HTML file appears as a regular Web resource.
Thanks for your answers. I think the way GWT has advanced AJAX, these
REST questions need serious reconsideration.
Walden
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
