RE: REST vs. OMA (not SOAP)

Mark

I agree that most of the world thinks SOAP=RPC and that this is too
limiting. Not everyone does though, for example ebXML Messaging is very much
"document" focused. The funny think is that both use XML to describe the
"meat" of the message whether it is a Purchase Order or remote procedure
parameters - there therefore ought to be scope for achieving a common
approach and therefore a common architecture.

I do think there is a need for some kind of "method" name in the SOAP
envelope. This is needed for both RPC and document style SOAP. For example
sending "AcceptOrder" might be a reasonable method name to use when sending
a purchase order to a supplier, just as "DeleteRecord" would be reasonable
when sending a delete record request to a remote database.

Whether or not it also goes in the HTTP header is dependent on how you want
to bind SOAP to HTTP.

I don't think it can ONLY go in the HTTP headers, since:
a) you might want to transport SOAP over something that is not HTTP and the
alternatrive binding might not have a "slot" to hold the method name, and 
b) you might want to digitally sign the SOAP message including the "method
name" - this is hard to do if the method name is only in the HTTP.

David

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Thursday, July 18, 2002 9:34 AM
To: Burdett, David
Cc: www-ws-arch@w3.org
Subject: REST vs. OMA (not SOAP)


Hi David,

On Thu, Jul 18, 2002 at 08:51:46AM -0700, Burdett, David wrote:
> <db>Apologies Mark but it seemed like a REST vs SOAP debate to me. This is
> why I think the current form of the debate is damaging.</db>

I understand.  It comes across like that too often.  But FWIW, it's not
because of anything REST proponents are doing.  We are (some more than
others, granted) very careful to highlight the differences.  IMO, it's
because the word "SOAP" automatically implies a style of use to most
Web services proponents, where the spec does not.  We've got to get
past this if Web services are going to be successful.

> SOAP can
> be used with either, even though most people use it like they're using
> the OMA, and without knowing any other way to use it (which apparently
> explains your associating of "SOAP" with RPC/OMA).  
> <db>I don't associate SOAP with just RPC, I also associate it enabling
> loosely coupled co-oeprating processes whose interfaces are defined as XML
> documents - as is required for the various business use cases describe in
> recent emails.</db>

Do you associate it with embedding a method name in the SOAP envelope,
when bound to HTTP?  

If so, that's a major architectural choice, very
different from the Web, as it extends REST's connector semantics from
being generic to specific.  This is a *HUGE* architectural difference,
seeing as REST's principle value-add, IMO, over other architectures like
OMA, is the generic interface.  It *drastically* increases coordination
costs between parties involved in the transaction.

> We are not here to rubber stamp current practice, because current
> practice is poor practice. 
> <db>By this do youo mean "SOAP is poor practice"? SOAP in its current form
> has many limitations, but it is a foundation on which other, richer
> protocols can be built AND it is being widely used.</db>

No, I meant what I said; current practice with SOAP is poor practice.
SOAP, the spec (1.1 and 1.2, not 0.9 or 1.0), is just fine.

> We're here to help Web services succeed,
> by leveraging those aspects of the Web that can help it succeed.  
> <db>Success, to my mind is determined by adoption more than anything else.
> SOAP is being adopted much more than REST - let's build on that.</db>

Hmm, no.  REST has several hundred millions of happy users, and millions
of happy developers.  If you've ever written an ASP or a servlet, you're
a REST developer.

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

Received on Thursday, 18 July 2002 12:39:34 UTC