RE: Consequences of SOAP GET to Web Services?

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Friday, June 14, 2002 5:07 AM
> To: www-ws-arch@w3.org
> Subject: Consequences of SOAP GET to Web Services?
> 
> 
> 
> The first and most obvious thing that this means, is that if the 
> underlying protocol is HTTP, that a SOAP developer must be aware of 
> that fact.  In other words, it is counter to Web architecture to treat
> SOAP as a layer when bound to HTTP, which virtually all SOAP 1.1 based
> Web services do.

You missed your calling as a lawyer, Mark :~) It's likely that some
members of the TAG believe that.  That's not an "obvious" implication
of the finding.  

> 
> Today, for us, this means that D-AR003.1[3] is incorrect 

No, and that's not the rough conclusion of our exchange, either.
The point of the TAG finding as I see it is to *allow* SOAP 1.2
to be integrated cleanly with "the Web", and to define that
as best practice.  "The Web" in my reading of the TAG discussion
means "resources identified by URIs," so they mandated that a
web service be identifiable by URI, which implies that at safe, 
idempotent service have its representation retrieved by GET.
Where does it say anything about "semantics of application
protocols?"  

[In all friendliness, as someone who has warm fuzzy feelings about
REST, this legalistic distinction between application and transport
protocols and the semantics they imply is not a winning argument ... you
got nowhere with it on xml-dev.]

 
> This decision also highlights the value of D-AR003.2[5], the recently 
> added draft requirement on an "a priori interface".  "GET" is a key
> method of this interface, as are the other HTTP methods that 
> operate on  resources,

I'm quite sympathetic to this point.  There really is something to be
said for being able to assume some basic functionality of a service,
but we need to think this through in realistic use cases ... DELETEing
a travel agency reservation resource makes sense, by what happens when
one DELETEs a stock quote?  PUT makes sense for a lot of things too ...
but not web services that imply a computation ... But let's not put
a requirement on ourselves just because it seems like a logical 
implication of the TAG finding.  


> for our work.  Primary amoungst them, I believe, is that the "assumed 
> architecture" that many (most?) WG members have in mind - the one that
> looks like OMA/CORBA - does not have very much to do with Web 
> architecture, and any architectural decisions that are made assuming
> that it does, will inevitably meet with objection from the TAG if we 
> incorporate them into our work.

As others said, this assertion requires a lot more justification before
we can really discuss it intelligently.  But speaking for myself,
the XMLP group went along with the TAG finding quite enthusiastically
because it made a lot of sense, especially in the context of the 
discussion surrounding the Google API and how a URI-based approach would
be so much easier to implement and cleaner to integrate with the Web.
It didn't go along because it feared to oppose the TAG's presumed 
authority, and if the TAG objects to an architecture that a consensus
of this WG finds sensible, I suspect that we will push back.

Finally, you'll get a better reception with an argument along the lines
of "you CAN do CORBAish things with web services, but you'll be sorry" 
(for reasons which you'll have to elaborate) rather than "Thou SHALT NOT 
do CORBA-ish things with web services."

Received on Friday, 14 June 2002 08:45:28 UTC