- From: Mark Baker <distobj@acm.org>
- Date: Tue, 28 May 2002 16:40:46 -0400
- To: Eric Newcomer <eric.newcomer@iona.com>
- Cc: www-ws-arch@w3.org
Eric, On Tue, May 28, 2002 at 04:09:35PM -0400, Eric Newcomer wrote: > Mark, > > Yes, this is what I was asking, thanks. One more clarification though -- do Good to hear! > you mean adding headers and methods within the URI string? No, within the protocol(s). URIs continue to act purely as identifiers for objects/resources. Let me first explain how I'd do it with HTTP, but without SOAP. I'd define extension headers as HTTP headers, perhaps using RFC 2774 if I needed mandatory extensions (like mustUnderstand in SOAP). Extension methods would be defined as new HTTP methods. If I were using SOAP as a layer 6 protocol, without HTTP underneath, I would create SOAP headers, and methods within the SOAP body. But I'd continue to use the REST style, so I'd use generic methods like HTTP does. If I were using SOAP as a layer 7 protocol, bound to HTTP, I would create SOAP headers if the headers were relevant to POST operations (like transactions, message ids, and other stuff that matters for side-effect inducing changes). If the headers were more for query like operations, then I would define them as HTTP headers so that I could use them with HTTP GET. If the headers are suitable for both, then I'd define them in both HTTP and SOAP, but make sure I have the same behaviour for each. That last one is a bit icky, but IMO, it's the price you pay (with SOAP) for building protocol extensibility into the body of the message, because GET has no body and so can't use SOAP on the request. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@acm.org http://www.markbaker.ca http://www.idokorro.com
Received on Tuesday, 28 May 2002 16:31:57 UTC