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

I really think we should remove any text describing a REST style of Web services.  It's inconsistent with the definition of a Web service in the introduction.

I have no problem including some general positioning information, and perhaps even some compare and contrast information would be helpful.  However I would also caution us against including commentary in a descriptive spec, which should contain objective text as much as possible rather than opinion or perspective - and much of the REST vs Web services debate is based on a difference of opinion.  Meaning it's probably better to omit it than include it.  I realize the WG has agreed to include some text on the topic, so I don't expect that we will really get to consensus on removing it all, but let's try to keep it to a minimum and avoid any definition of a Web service as something based on REST.  It's not.

Eric





-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Michael Champion
Sent: Friday, January 23, 2004 1:37 AM
To: www-ws-arch@w3.org
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.]

Received on Saturday, 24 January 2004 06:42:54 UTC