On 17 sep, 16:21, walden <[EMAIL PROTECTED]> wrote:
> On Sep 17, 5:37 am, Thomas Broyer <[EMAIL PROTECTED]> wrote:
>
> > 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 didn't say it won't scale at all, just that it won't scale *as well
as* a "RESTful web service".
> I would like to have a scenario.
The whole thing is about caching and the like (intermediaries, etc.).
For example, we're building an app that manages employee folders
(containing files such as contracts, resumes, IBANs, etc.) through
workflows. Each employee folder is based on a template, meaning all
employee folders have the same subfolders; this template however
cannot be replicated at the GWT level because it has to evolve
independently of the GWT client and moreover you can only see some
subfolders depending on who you are and which employee you're looking
at (you might see the "contracts" subfolder for secretaries but not
for managers). On the other hand, the ACLs are only changed during a
nightly batch update (when the admin changes the ACL rules, they won't
be effective until the nightly job runs). This means that for a given
an authenticated user and employee folder, the list of subfolders
won't ever change during the whole day.
This list being dependent on the authenticated user (well, actually,
his "role", the user groups he belongs to), there's a resource (a URL)
for each user+employee pair (let's say: /subfolders?
employee=12345678&i-am=userA), and the server can thus send an
"Expires: <next midnight>" header. Now, the user browser will use it's
own, internal, non-shared cache to serve each subsequent request.
Now, our app is for a big corporation with several companies and
sites, so we do have intermediaries. We could then just as easily tell
them to cache those lists provided you're authenticated ("Cache-
Control: proxy-revalidate"; or even better an extension token if we
have some control over the intermediaries: "Cache-Control: private,
role=myRole"), and change our URLs to share them among users (/
subfolders?employee=12345678&role=myRole). That way, with only little
changes, all users (with the same role) passing through the
intermediary use its cache rather than going to the origin server.
Another scenario: if we know for sure than a given resource will only
be ever accessed through a given intermediary, we can safely ask it to
cache the resource: POST requests (or PUTs or DELETEs) will go through
this intermediary and invalidate its cache.
Just some thoughts... (and only because with GWT-RPC everything is a
POST, and as a result with no need to scale the application server)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
