Re: No consensus on draft findings on Unsafe Methods (whenToUseGet-7)

David Orchard wrote:
> Clearly there is not consensus in the community on this issue.  

First, a procedural point.  It is not the TAG's role to ascertain what 
the consensus of the community is.  The TAG's role is to write down how 
the web architecture actually works and to do whatever possible to 
ensure that standards and tools avoid breaking it.  And as of last 
meeting, there was what smelled to me like consensus on the TAG that the 
GET method SHOULD be used for safe/idempotent operations, per the 
current Web architecture.  With a single dissenting voice, not 
surprisingly Dave's.

However, I don't believe that in fact Dave disagrees with the 
proposition that the Web architecture as it stands today does call for 
the use of GET in this scenario.  I believe he's pointing out the 
obvious reality that Web Services just don't do it that way and a lot of 
people think they are useful, so let's not derail them.  This is a 
reasonable point of view and one that I agree with.  (Although I'm 
beginning to wonder if so-called Web Services really have anything to do 
with the Web).

Given that, it occurs to me that there is a reasonably straightforward 
way forward that makes everyone happy.  There is a certain proportion of 
Web Services operations that smell a lot like read-only procedure calls: 
stock market quotes, the new google API, and so on.  These are precisely 
the ones that it would be nice to be able to bookmark and GET and cache 
and so on, and SOAP currently gets in the way.  But it doesn't have to.

I propose that for those proportion of SOAP requests that consist of a 
service name plus a sequence of name-value-pair arguments, we devise a 
simple url encoding.  Wouldn't be hard.  Here's the canonical RPC 
example from http://www.w3.org/TR/xmlp-scenarios

  <r:GetLastTradePrice 
env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
              xmlns:r="http://example.org/2001/06/quotes">
   <r:Symbol>DEF</r:Symbol></r:GetLastTradingPrice>

This becomes something like

http://example.org/SoapGet?serv=http://example.org/2001/06/quotes&Symbol=DEF

I don't provide the encodingStyle - let's assert that if you do it this 
way you get soap-encoding by default (or in fact that that's all you can 
have).  To simplify, let's say that the service name is by a default a 
relative URI reference with the base established by the that of the URI 
itself, thus

http://example.org/SoapGet?serv=/2001/06/quotes&Symbol=DEF

Nothing else changes - you still get the same XML back.  You need to
establish a convention for signaling that this url-encoded call be
routed through a SOAP handler.  Given that, I could write the
apache code in an afternoon to, on the server side, fake up the XML SOAP
envelope and pass it to the SOAP handler which would never notice
the difference.

Obviously there are a ton of SOAP scenarios where this won't work, but 
that's OK, they probably don't benefit from GET semantics anyhow, and 
this is clearly not trying to be a complete solution.

The best group of people to do this would be those working on SOAP 
itself, but if they're too late in the process or not interested or 
whatever, a canonical way to do this could be hacked out and defined and 
implemented and done by this time next week.

And I think it makes the problem go away. -Tim

Received on Sunday, 21 April 2002 18:25:35 UTC