- From: Alan Davies <ADavies@SeeBeyond.com>
- Date: Fri, 15 Mar 2002 12:30:42 -0800
- To: www-ws-arch@w3.org
Hi Mark, You say below that between them, the HTTP GET PUT POST and DELETE commands are capable of representing what you describe as any "distributed hypermedia state change". Do you consider that the invocation of a remote procedure (which is at least one purpose that POST is commonly used for nowadays) can be described as one, or perhaps two, distributed hypermedia state changes, or is it out of scope of that description? Logically a remote procedure call potentially involves the transfer of data to and from the remote procedure, and any state change is 'hidden' behind the remote procedure itself, so it would seem that it is out of scope of the description. If this is so, does this mean that HTTP should not be used for such purposes? Regards, Alan Davies, SeeBeyond. -----Original Message----- From: Mark Baker [mailto:distobj@acm.org] Sent: Thursday, March 14, 2002 8:37 PM To: RogerCutler@chevrontexaco.com Cc: www-ws-arch@w3.org Subject: Re: D-AG0017 - Business Infrastructure > Note that some of these issues are being addressed, at least to some degree, > in the OASIS ebXML Messaging Services TC > (http://www.oasis-open.org/committees/ebxml-msg/ > <http://www.oasis-open.org/committees/ebxml-msg/> ). There may be some > questions, however, about whether this work conforms to the W3C vision of > web architecture (Mark Baker has indicated this but has not specified > exactly what the issues are) or of completeness. I don't recall commenting on ebXML messaging, but since you're asking, yes, it has some major issues too. Not as many as, say, BTP (since BTP introduces new application semantics), but still quite a few. The common issue with virtually all Web services protocol specs out there today is that they tunnel over POST. That is, they ignore the meaning of POST that HTTP assigns, and instead place their own meaning over top. That none of these specifications use PUT or GET is a *major* architectural issue, as GET, PUT, and POST form a kind of "complete triumvirate" of state transfer operations, capable of representing any distributed hypermedia state change (or state inspection, ala GET - plus you need deletion, with DELETE). To be Web architecture friendly, you have to use POST, even with SOAP, to *mean* POST. A side effect of this, is that using SOAP with HTTP and the default binding in a Web architecture friendly way, requires that you still use HTTP (and not SOAP - gasp! 8-) for doing GET and PUT to the same URIs you were POSTing to. For example, you might POST a SOAP message containing an XML vCard to http://mysite.org/addressBook in order to add an entry. Then to view the address book with the new entry, you just do a GET on it. A PUT on the address book would overwrite what was there before, and DELETE would remove it. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com
Received on Friday, 15 March 2002 15:31:27 UTC