Re: Consequences of SOAP GET to Web Services?

Hi Mike,

On Fri, Jun 14, 2002 at 06:44:53AM -0600, Champion, Mike wrote:
> > 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.  

How not?  Please elaborate.  A developer needs to provide the HTTP
"Web method" to be used (directly or indirectly) when using SOAP 1.2
bound to HTTP.  Even indirectly, a developer has to do something
differently when using SOAP with HTTP than it does with SOAP with
SMTP, for example.

> > 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.

Right.

>  "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?"  

I guess we have different interpretations of TAG findings.  I've seen
nothing that limits the definition of the Web to resources identified
by URIs.

> [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.]

Well, I expect that an audience of distributed systems architecture
gurus would have a better understanding of that issue than a group
of markup weenies. 8-)

> > 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.  

Hmm.  The issue with generic methods isn't that all methods must be
implemented, but that each makes sense.  For example, a non-generic
method would be "GET-STOCK-QUOTE", which doesn't make sense when
invoked on a weather report.  "DELETE" on a stock quote "makes sense";
the client is attempting to delete the stock quote so that others
cannot access it.  It will just likely be met with a 403, Forbidden.

> 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."  

Where did I ever say that?  Perhaps you should reread the last line of
the message where I asked for discussion on what WG members thought
this issue meant to us.  I've presented my *opinion* that developing an
architecture that looks like OMA/CORBA is a bad idea, that's all.
I think I've done enough explaining of the "why" in the past to
deserve to pop my head up with a value judgement every once in a
while. 8-)

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

Received on Friday, 14 June 2002 09:20:47 UTC