W3C home > Mailing lists > Public > xml-dist-app@w3.org > August 2001

Re: POST abuse?

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 27 Aug 2001 09:41:54 -0700
To: Paul Prescod <paulp@ActiveState.com>
Cc: xml-dist-app@w3.org
Message-ID: <20010827094149.A30118@mnot.net>
On Sat, Aug 25, 2001 at 05:00:18PM -0700, Paul Prescod wrote:
> > 
> > However, I don't know that going to pure-GET is necessary to fix
> > this; merely requiring a 1-to-1 service-to-URI mapping would do the
> > trick.
> 
> Could you define "service" here? The WSDL definition seems much more
> granular than what I think you are talking about. I'd also appreciate if
> you describe where you think this mapping takes place and what it looks
> like. Are we talking about soap: URIs?

Ultimately, perhaps service is defined as what needs to be defined as
an addressable chunk. Some services might be defined to be
unaddressable; if the service provider doesn't care about addressing
things at a finer grain than http://www.example.com/services (and
thereby getting the associated benefits), who's to stop them? 

I.e., it happens in our heads.


> I was thinking recently about what you would need to construct a string
> that represented a SOAP query. You really can't compress the message
> much in generating this representation. You need:
> 
>  a) end-point URL
>  b) XML namespace
>  c) method name
>  d) SOAPAction
>  e) parameters
>  f) expansions for any "cookies" or "handles" you've passed around.
> 
> SOAP could be a lot more addressability friendly if it would get rid of
> some of that magic stuff. If the SOAPAction were defined to be
> URI#methodname that would help. 

Or if it disappeared.

 
> But the "cookies" and "handles" are going to be the real killer. We
> would have to strongly deprecate the use of those sorts of things if we
> want to maintain addressability.
> 
> Another issue is that you don't want every method result to be
> addressable. Some non-cachable method results should be addressable
> (e.g. currentStockQuote/IBM). But the result of the "please accept this
> purchase order" method is not repeatable. The second time, you've
> submitted a different purchase order.

It seems like you're equating addressability with repeatability; from
what I've read so far, this doesn't align with REST. 


> The ResponseCache stuff is interesting. Evaluating XPath expressions
> seems quite expensive but I guess it is your business to worry about
> that, not mine. <0.5 wink>

Heh. I started with XPath because it's well-understood, and
necessary, in some cases. I think things might evolve where a number
of different key systems might be defined (of which some would be
more sax-friendly). E.g.,

  <messageKey type="simple">
    <ns>http://www.example.com/</ns>
    <localname>foo</localname>
  </messageKey>

Cheers,

-- 
Mark Nottingham
http://www.mnot.net/
 
Received on Monday, 27 August 2001 12:41:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:03 GMT