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

Why, an extensibility model to separate headers and bodies, as well as
mustUnderstand/mustIgnore semantics, and targetting intermediaries with
headers, and meps and ...

I though that was obvious.  Try to add a mustUnderstand header targetted at
an intermediary into an HTTP message.

Dave

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

Received on Friday, 23 January 2004 12:35:26 UTC