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

This has been proposed [1] before. It's certainly possible, IMHO.

The main issue is that it can't be called a binding - because it doesn't 
in fact provide an abstract, transparent messaging substrate for SOAP; 
instead it severely limits it, by imposing:

  * RPC only
  * request-response MEP only
  * Section 5 encoding only (and references would need to be addressed)
  * no Headers (except for those that can be abstracted out as HTTP 
features)
  * no support for SOAP envelope versioning, etc.

I've mused in the past that it might be itself considered a feature (or 
whatever the current term is) of the HTTP binding; "if you fit the 
profile of all of the above restraints, and your request is 
safe/idempotent, you can use the GET feature."

XMLPWG didn't show much interest [2] in this approach, and that isn't 
surprising; it doesn't fit cleanly into SOAP, and the use cases, 
although evident now (because so many people see SOAP as just 
RPC-using-XML-over-HTTP), are pretty uninteresting in the face of where 
most vendors want to take SOAP. I've already spoken about the dubious 
value of HTTP caching to SOAP, so the only remaining tangible benefit is 
linking/bookmarking.

Because of this, I agree that it's not a good idea to mandate that 
XMLPWG "fix" this problem (unless a hitherto non-evident desire to do so 
is displayed). If it will get us past this, I'll be happy to help put 
together a NOTE which defines a HTTP binding feature that accomplishes 
this, provided that some current XMLPWG members are involved, and that 
it doesn't impact XMLPWG's schedule, which seems to be one of David's 
concerns (justifyably, at this extremely late stage).


1. http://lists.w3.org/Archives/Public/xml-dist-app/2002Feb/0327.html
2. http://www.w3.org/2000/xp/Group/xmlp-issues#x133



On Sunday, April 21, 2002, at 03:25  PM, Tim Bray wrote:

> 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
>
>
--
Mark Nottingham
http://www.mnot.net/

Received on Sunday, 21 April 2002 23:49:44 UTC