axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Baker <dist...@acm.org>
Subject Re: SOAP 1.2, GET, and Axis
Date Mon, 08 Jul 2002 05:02:51 GMT
On Sun, Jul 07, 2002 at 09:00:43PM -0700, Steve Loughran wrote:
> well there is a conceptual cost, and a load cost on the infrastructure
> related to inability to cache. But as I observed before, caching is
> problematic as you dont know how long something will be valid. Unless
> if-modified-since goes through the system (which is actually no bad thing),
> you cant safely cache anyway.

Caching is the least of the benefits.  Being able to hand around a URI
to the bazillions of tools that know what one is, is probably the biggest
reason - or perhaps tied with this next one ...

The association of URI & GET is something that Web services sorely needs
IMO.  If you have a URI for a service that is only usable by POST,
then you don't know, a priori, what "magic content" you have to put in
the POST body in order to do the safe retrieval from that URI.  For the
Web, all URIs respond to GET, and everybody knows that (one of the
reasons why the Web doesn't need an IDL).

But I don't want to get into "REST benefits, 101" here, any more than I
have to. 8-)

> Regarding 'just define an equivalent header', what about mustunderstand
> headers. should all headers begin x-mustunderstand- with the convention that
> recipients handle it.

I'd use M-GET from RFC 2774.  This would have to be part of the RFC822
serialization as well.  i.e. if the envelope includes any mU=true, then
use M-GET, otherwise use GET.

The intermediary targetting mechanism would need some thought though.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Mime
View raw message