- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 1 Feb 2002 07:14:33 -0800
- To: Yves Lafon <ylafon@w3.org>
- Cc: Mark Baker <distobj@acm.org>, Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, xml-dist-app@w3.org
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/
Received on Friday, 1 February 2002 12:02:31 UTC