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

Hello Mike,

Here's my 2c.

You said :
> 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.
and
>...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...

The fact that there're no examples of complex (transactions, security,
whatever) REST services around doesn't mean that such services can not be
created.  All these complex features are implemented with SOAP headers and
supported by toolkits. The difference with REST is that all these complex
features can be equally implemented with the help of HTTP headers and
response codes if it's all happening over HTTP or by applying RESTful
properties with the help of some other outbound means if it's happening,
say, over TCP/IP; how this is done is unspecified and can be done by experts
who know what they're doing. Perhaps this is one of the (main) reasons we
see no new very complex RESTful services around, as it just feels kind of
safer and easier for a software developer like myself to go the way backed
up by major vendors/companies instead of, for example, trying to build my
own transaction protocol over HTTP.
But again it doesn't mean it's not possible to build a complex RESTful
service. Probably it might be better to express it in the text somehow.
Cheers
Sergey Beryozkin






----- Original Message -----
From: "Michael Champion" <mc@xegesis.org>
To: <www-ws-arch@w3.org>
Sent: Friday, January 23, 2004 12:00 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 :-)
>
>
>

Received on Friday, 23 January 2004 08:16:07 UTC