RE: Section 1.6 and REST - Can we make this more clear and useful ?

I strongly oppose the text because it does more harm to the document than
good.

The REST is just a style of architecture that makes the Web the most
successful distributed application.  The simplicity of this style does
nothing to prevent one from building complex business solutions. In fact, it
is the very simplicity that allows such a diverse range of Web applications
to flourish.

SOAP is a specific technology.  One can use it RESTfully or non-RESTfully.
If one uses it RESTfully, one gets the nice architectural properties such as
reliability, scalability, extensibility, etc ... .  If one uses it
non-RESTfully, one has to prepare for the aftermath of tight coupling (the
old wonderful world of distributed objects). 

In short, saying that REST is only useful for simple applications, is
totally misleading.

Hao

-----Original Message-----
From: Michael Champion
To: www-ws-arch@w3.org
Sent: 1/23/2004 5:42 PM
Subject: Section 1.6 and REST - Can we make this more clear and useful?


In fulfillment of my action item, initiated by Roger's  comments in 
http://lists.w3.org/Archives/Public/www-ws-arch/2004Jan/0144.html and 
some pushback on my assertion that the Web is an instance of an SOA:

Roger summarizes his thoughts as follows:

"The REST style, in my view, does not lend itself either to business
applications of the RPC style of Web services nor to automating via Web
services core business processes that involve complex document
exchanges. Both of these business applications benefit from the layers
of protocols that go beyond what is allowed in the REST architecture.
There may be, however, other business functions for which the REST
approach may be more appropriate. In particular, I think that there may
be a good case for using the REST style of Web services in circumstances
where a simple service is to be provided to a very large and possibly
diverse audience who are "on their own" how they use the service. "

Here's how I would summarize my thoughts at about this level of detail; 
  I'd appreciate some immediate pushback if this seems wrong and not 
just in need of more elaboration and justification:

The REST style lends itself to simple business services when a) the 
operations of the service correspond directly to the "CRUD" operations 
of the REST generic interface; b) when the semantics of the data being 
represented are well-defined and widely supported by software; and c) 
when HTTP is the only protocol of interest in the service environment.  
[1]  More complex services that use something analogous to "hyperlinks 
as the engine of application state" *may* be effectively developed 
using the REST style, but there are few real-world examples and this is 
at best a bleeding edge approach.  SOAP provides a framework for adding 
additional features at the infrastructure level -- such as reliable 
messaging across multiple network nodes or over different protocols, 
business-level transaction processing, orchestration/choreography of 
multi-part services, and security features such as identify management, 
encryption, and authorization -- that are not specifiable using the 
pure REST style. In SOAP and REST can be used in conjunction with one 
another, but again there are few real-world examples and tools 
supporting SOAP 1.2 and WSDL 2.0 that enable this in principle  have 
not yet been deployed.

To summarize, REST is an appropriate style for simple services deployed 
over the Web; SOAP adds more and more value as complexity increases 
because it provides a framework for technologies  built on SOAP that 
can add reliability and security at the infrastructure rather than 
application level.


[1] For example, consider an image storage/querying/manipulation 
service.  One could POST (or PUT) images in JPEG format and get back a 
URI identifying the stored resource; one could GET the URI of a known 
image to retrieve it, DELETE the URI of a known image, etc.  Additional 
services such as image scaling, rotation, and format conversion could 
be specified as additional parameters (in the URI or HTTP headers).  
Queries might be handled by a GET on a catalog resource, with URI 
parameters specifying the attributes for a match [numerous devilish 
details would have to be specified, of course, for a useful service.]