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

Good we are not putting the text into the document.

A number of points:

1. The URI is just an identifier and it is not a message carrier
(except the query part) so one does not encode the whole SOAP message. 
You either POST the message or the URI of the message so others can GET it.
2. If you want complex REST and transaction-oriented example, we have built
typesetting systems that we use to publish books, those real complicated
books for professionals.
3. Using SOAP does not mean it is non-RESTful. However, if one wants to use
it
in a non-RESTful (RPC) way, one really needs to justify it.
4. What is the architectural significance of SOAP after its moving away from
the
role of RPC encoder? 

Hao



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



On Jan 23, 2004, at 6:35 AM, He, Hao wrote:

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

I don't have any particular desire to put this in the document.  I'm 
stating my personal views using Roger's expression of his view as a 
starting point.  The very LAST thing I want to do is reopen the REST 
debate if it is divisive; the point I took from the discussion 
yesterday was to find a *useful* way to summarize what we learned from 
the debate.

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

I pretty much agree (although I'm not particularly happy by saying that 
the alternative to REST is "distributed objects." But we've never 
managed to come up with a good term for "non-REST".

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

Well, I think this is the crux of the matter.  I don't see any example 
of Web services as we define them, or "SOA" as the analysts and 
marketers (and several of our companies!) are using the term, that use 
REST in a complex way. Maybe we will; I wouldn't be surprised, but I 
want to see the proof before putting my own credibility on the line.

Anyway, this is where I come down (personally, not necessarily what I 
want the WSA document to say): REST is demonstrably useful and 
efficient for straightforward, information-oriented, Web-based 
automated services.  Amazon is a real world example; their RESTful 
interface for programatically looking up information on books is quite 
a bit more popular than their SOAP/WSDL distributed object API.  Beyond 
that, I just don't know of compelling examples, and the lack of a 
support for doing much with SOAP for requesting data in a RESTful way 
seems like a show-stopper for using REST in a multi-network, 
high-security, transaction-oriented manner.       (I'm referring to the 
fact that there's no obvious way to encode a complex SOAP message in a 
URI). Bottom line: REST is a tool that Web services / SOA developers 
should know how to use and when it can be used most effectively, but 
not treat it as a philosophy to be applied whenever a distributed 
system needs to be built.  (That message seems to go over well with the 
audiences I speak to on this subject)

As for the WSA document, I'm reasonably happy with what we say in the 
current draft. Roger thinks we can put in more clear and useful 
language summarizing what  we think about REST.  I'm sure that each of 
us as individuals can do so, but I doubt if we can get much clearer 
than the current document text and maintain a consensus.  But I said 
I'd try :-)