Re: Issue 133, and permitting no body

I realise I should be more explicit about the motivation for this.

(with my Akamai hat on)

A number of people are using SOAP as a convenience; they're just
slinging typed bits around, and aren't doing messaging, transactions,
etc.

These people really are using SOAP as a 'smart media type' (see
previous message ;), and would like to be able to use the facilities
that the Web offers, specifically, caching.

For example;
  - the ubiquitous getStockQuote
  - desktop programs which need to download non-user-specific blobs
    of data regularly (unfortunately, I can't be more specific).
  - distributing catalogs of products, etc.

In each of these cases, the primary attraction of SOAP is that there
is a well-recognised datatyping convention that's easy for developers
to plug in. Each of these applications also need the performance
gains of using caching.

In most current SOAP implementations, it's difficult or impossible to
do anything but RPC; as a result, one is forced to use POST, losing
any possibility of caching. Even if your SOAP toolkit does support
deserialisation of individual messages (bravo!), it's difficult to
communicate to other developers, who often equate SOAP with RPC.

What I'd like to see explicit design of a SOAP binding which uses
GET, so that these users can exploit caching. In its simplest form,
this would be a GET to a resource with a SOAP response; it would
imply that the SOAP request is static and linked to the URI.

A slightly more flexible approach would allow one to coordinate the
encoding of the URI in the WSDL; for example, if the endpoint URI
were

  http://www.example.org/GET/SOAP/ENDPOINT?stockTicker=$

the '$' could identify portions of the URI to consider typed
arguments, as specified in the WSDL. (This is just doodling, but
hopefully you get the idea; it's to encode the section 5 data model,
rather than the XML, in the URI). 

The main point is to make GET a first-class binding of SOAP, so that
caching can be exploited. This may involve some out-of-band
coordination to get the encoding of the URI right, but for these
simple cases, I think that's acceptable (and it may be that it can be
coordinated in WSDL anyway).

Regards,



On Fri, Feb 01, 2002 at 07:14:33AM -0800, Mark Nottingham wrote:
> 
> I like this! I can see four possibilities (not mutually exclusive);
> 
> 1) GET w/ SOAP envelope serialised in URI, response carries envelope
> 2) GET w/o any SOAP envelope, response carries envelope
> 3) POST w/ SOAP envelope, 303 See Other, #2
> 4) GET w/ body
> 
> 1 is interesting but tricky to get the serialisation right (both in
> terms of length and a canonical encoding). Remember that the *entire*
> envelope becomes the cache key, which isn't very useful...
> 
> My concern with disallowing the SOAP body is that people will
> inevitably just stick something body-like in a header.
> 
> Mark seems to be aware of my misgivings about GET-with-body. :)
> 
> Also, remember that SOAP headers can be mapped to protocol-specific
> features; there's nothing stopping Bob from taking his nifty
> transactional SOAP header and describing how to serialise it as a
> HTTP header.
> 
> So, my money is on #2&3. I'd also note that the entail the least
> amount of work for the WG.
> 
> 
> On Fri, Feb 01, 2002 at 01:30:36PM +0100, Yves Lafon wrote:
> > On Thu, 31 Jan 2002, Mark Baker wrote:
> > 
> > > Noah, this is one of those "web architecture" issues again.
> > >
> > > Encoding a SOAP envelope in a URI is using GET to tunnel that envelope,
> > > and isn't respecting GET semantics (which are "give me a representation
> > > of the resource identified by the Request-URI").
> > 
> > Well, having the envelope sent as a parameter is OK.
> > Another way to look at the GET method would be to have inbound one-way
> > messaging, but you need to have a way to identify that you will get
> > something without a body.
> > 
> > An example would be to do a POST to register a listener to a resource, you
> > want to listen to the weather in "foo" city
> > 
> > POST /register
> > <blah>
> > 
> > HTTP/1.1 303 OK
> > Location: http://www.example.com/weather/foocountry/foocity
> > 
> > And then you get "events" (ie, weather information) using GET method. Of
> > course it can be cached and ETag or Date revalidation can be used to
> > detect any new "event".
> > It is clear in this case that those GETs are idempotent methods.
> > 
> > -- 
> > Yves Lafon - W3C
> > "Baroula que barouleras, au tiéu toujou t'entourneras."
> > 
> > 
> 
> -- 
> Mark Nottingham
> http://www.mnot.net/
>  
> 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Monday, 4 February 2002 12:27:35 UTC