RE: Issue 5; GET vs GetLastTradePrice

Mike,

A few thoughts on optimization.  The web was optimized for the GET case -
default method for HTTP URIs, etc.

But we haven't really talked much about the downsides of this optimization.
Let's talk about some of them:
1. Lack of support for XML inputs.  GET is limited to only URI characters.
No multi-namespace documents allowed.  I tried to create a mapping between
XML and HTML form encoding (please note that the query parameters for URIs
are defined in HTML!!!) as part of the TAG work, but that didn't really
solve the problem.  We even had some discussion at the TAG level about
defining an HTTP QUERY verb that would allow an input document.  What I
can't figure out is why people that are ardent fans of XML would also be
ardent fans of ignoring XML on the input side of an operation!

2.  Optimization for GET means that optimization for another verb, say POST,
is harder.  Optimizing for POST means that supporting multiple protocols is
easier.  By focusing on 1 HTTP Verb, it means that the Web services
developer can more easily deploy their application to multiple protocols.
For example, in our workshop tools, a developer can visually "tick" which
protocols they want to use - HTTP SOAP/POST, JMS, SMTP.  Now very coolly,
our tool also allows you to deploy to form-encoded and URL-encoded as well.
But the models don't seamlessly work together when using form/URL-encoded
because of the data encoding issues.

3. The web security model is pretty badly broken in some areas.  The very
fact that a server can't time-out an HTTP log-in, means that most security
applications use cookie based authentication.  They then have either the
client punt the session or relying on the server to figure out a
"last-access" time based upon some state in the cookie.  I imagine there are
other things that could have been done at the protocol level, but they
weren't.  So the web optimization is very good at making sure that I could
paste the URL into an email and send it (as most sites don't pollute the URL
with username/password) but this seems like a failure in design rather than
a feature built-in.  This trade-off means that the application developer is
now polluted with dealing with cookies/sessions/state, but we can still cut
and paste URLs!

Perhaps the web is kind of like a virus.  It was completely optimized for
getting it's addresses all over the place.  Every other property was
sacrificed on the altar of propagation of human typable addresses.  I need
to think about this notion a bit more, and the ramifications, but it seems
to ring a bit true to me.

Effectively, GET is an optimization for a query operation.  This may be a
bad optimization for general program to program interaction, because
programs often want to do update operations or queries with complex input
arguments.

I think the best way to deal with these issues is to start talking about the
various use cases of developing deploying in a variety of situations.  And
then we can measure the trade-offs associated with each optimization.

There is even a third alternative.  Maybe there are NO generalized
optimizations we can make for web services because of the huge variety of
applications.  Therefore all we could really do is provide template or
"best-practice" optimizations, ie "If you want multiple protocol access then
prefer HTTP POST", "If you want ad-hoc client invokes of a well-defined and
published protocol, don't do multiple protocols and heavily use HTTP GET",
etc.  The point being that maybe Web services is bigger than the Web, in the
sense that the Web made certain optimizations that Web services can't make
because Web services is targetting a wider scope of applications.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Champion, Mike
> Sent: Thursday, January 02, 2003 6:34 AM
> To: www-ws-arch@w3.org
> Subject: RE: Issue 5; GET vs GetLastTradePrice
>
>
>
>
>
> > -----Original Message-----
> > From: Mark Baker [mailto:distobj@acm.org]
> > Sent: Wednesday, January 01, 2003 9:40 PM
> > To: Christopher B Ferris
> > Cc: www-ws-arch@w3.org
> > Subject: Issue 5; GET vs GetLastTradePrice
> >
> >
>
> >
> > My resolution for the new year is to not get side-tracked into a
> > wandering perma-thread.  I'm going to focus solely on the
> > value of URIs
> > and GET as a superior means of retrieving data, whether a human is
> > nearby to interpret it or not.
>
> Uhh, I thought that was last year's resolution, which you
> kept quite well,
> and helped persuade the TAG and XMLP group to add the web
> method feature to
> SOAP 1.2.  What further do you want this year?  The WSA
> definitely takes
> SOAP 1.2 and the various discussions that led to the web
> method feature as
> authoritative input.  I think we've acknowledged that the
> example you point
> to in Issue 5 is pretty was created by a mass cut-n-paste
> from some other
> pre-web-method document.
>
> If you want the tool vendors to support the web method
> feature, this isn't
> the group you have to persuade.
>
> BTW, I personally suspect that we'll resolve Issue 5 to say
> something like
> "trade a few parameters for some info" requests should IN
> GENERAL be done
> with HTTP GET .... but acknowledge that both Web and SOAP
> toolkits currently
> make using POST the path of least resistance.  What are some
> of the points
> in favor of using GET vs POST in a particular scenario?  I
> can think of:
>
> GET: - allows hyperlinking to a "web service" invocation,
> supports HTTP
> cacheing ....
>
> POST -  allows arbitrarily large amounts of data to be passed
> to the web
> service invocation, avoids URI encoding problems with
> non-ASCII data ....
>
> Thus, I can sympathize with the tool vendors (and original
> SOAP authors) who
> used POST because it always works even though is sub-optimal
> for a large
> class of situations, rather than putting in the logic to
> determine whether
> GET or POST is more optimal for a particular situation. Our
> job, to beat my
> favorite dead horse once again, is  a matter of defining the
> conditions
> under which one or the other is more appropriate.   Your
> assistance (and Roy
> Fielding's, of course) would be welcomed to craft the
> language defining
> those conditions for the WSA document.
>
>

Received on Thursday, 2 January 2003 13:17:16 UTC