axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: SOAP 1.2, GET, and Axis
Date Sun, 07 Jul 2002 18:19:41 GMT

----- Original Message -----
From: "Sam Ruby" <>
To: <>
Sent: Saturday, July 06, 2002 14:49
Subject: Re: SOAP 1.2, GET, and Axis

> I don't follow.  The argument seems to be that GET can do X but can't do
> Y, so we will discourage the use of GET for X?

well, SOAP1.2 says 'you should use GET for all your side effect free
querie', but I think they should really say 'all the ones that dont need
soap headers'

> > -If and when we do implement support for GET server side, we will
default to
> > returning http headers to indicate no caching; this will stop the
> > infrastructure from caching and returning old queries when a non-side
> > effecting request has invalidated the number. To work with the Web's
> > systems, SOAP implementations would need to support if-modified headers
> > let callers probe for a query being invalidated through external
> At a minimum, couldn't this be supported in the HTML binding for a
> particular web service, or in the WSDD?

interesting q. it should be in the metadata about  method, certainly,
perhaps even metadata that the method sends back in the response, depending
on the problem.

e.g. the classic stock quote service should return an expires header that
indicates that queries are valid for about 5 minutes, except when the
exchange is closed, in which case it can return a validity of hours.

another could be the quantity in stock service, GET

here the return value is valid until a someone purchases something...if a
caller makes the purchase themselves they should know to invalidate the
value, but if someone else does the operation there are no cues. How are we
going to say 'expires if you do something side-effecting on this SKU (or
this warehouse :), or if someone else does, so fetch every five minutes.
Saying Expires: now+5 minutes is easier.

One thing that we could consider is handling is-modified-since tags. This
would have to be done on an individual basis on an object or attribute, here
we could cache the timestamp that the stock quantity changed, so we could
return not-modified when appropriate. This would be something that people
would have to code deep into their design, of course, even into the database

Is there explicit support in SOAP1.2 for the expires, if-modified stuff, or
is that just implicit through the use of HTTP as a transport?

> > SOAP1.2 pushes explicit use of URIs. But some of the examples are
> > almost repeats of the SoapAction header issue: if content is duplicated
> > in the body of the message, then you have to deal with differences
> > between header and body. A zero duplication model is less brittle.
> This is a losing argument.  The response will simply be to not duplicate
> what exists in HTML.

I agree, but at the least they could fix the example so there is no

View raw message