RE: A viewpoint on harvesting REST

Mark,

I did some digging into the use of WSDL with GET as part of TAG discussions.
It appears to me that WSDL can fully describe a URI.  The UrlReplacement
section shows how parameters can be specified.  I do think the WSDL group
has a bit more to do in this area - such as more than zero examples of this,
highlighting it more strongly in the spec, integrating with the SOAP 1.2
work - but they have on their issues list update to deal with soap 1.2.  I
do think the limitations of URI encoding versus XML encoding should be
described in this context, but that seems like a web architecture issue and
not a ws arch issue.  Especially with experts like Roy Fielding and Tim Bray
on the TAG.

I think that we are at an impasse on how to integrate REST with Web services
from the perspective of methods names.  I believe that the compromise
position is that web services should expose GETtable URIs, but that any
other non-safe methods can be done in specific method.  The REST principle
is that all methods have to be generic.  This is the whole enchilada,
whether you have generic methods or methods in the body.  I could go into
paragraphs of prose on why I think that my middle-ground approach is
reasonable, but I think that won't solve the heartburn that the REST folks
have about using ONLY generic methods.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Mark Hapner
> Sent: Wednesday, July 31, 2002 12:04 AM
> To: ws-arch-public
> Subject: A viewpoint on harvesting REST
>
>
>
> I would like to present a perspective on REST harvesting that
> builds on
> what I found to be a very positive and enlightening
> discussion on this
> topic.
>
> I find it hard to write this without referring to
> 'implementation' so I
> ask your indulgence on this.
>
> Some observations:
>
> HTTP GET and POST are the primary building blocks of the web.
> Although
> their use is not always in accordance with the REST architecture, the
> REST resource model is the best architectural description of
> the web we
> have.
>
> The Soap header is the fundamental building block for web services.
> Combined with MIME/DIME enveloping, Soap and its description
> facility,
> WSDL, are the best architectural description of web services
> we have. (I
> also include the ebXML stack as part of the larger Soap web services
> umbrella).
>
> A conclusion:
>
> There is no technical reason why Soap cannot embrace and extend the
> existing web. It should; and, WSAWG should reinforce its
> commitment to
> this goal.
>
>
> What does it mean for Soap to embrace the existing web?
> -------------------------------------------------------
> By embrace, I mean fully support the existing REST resource
> model as web
> services.
>
> Soap WSDL should be able to provide a basic description of a URI, its
> support for GET, its GET 'query' and the MIME type it
> returns. Ditto for
> POST. Soap should provide a binding that allows web service
> endpoints to
> offer services at the HTTP level without requiring enclosing
> Soap wire
> enveloping on request or response. This will allow Soap WSDL
> to be used
> to describe existing web sites and opens them to access from
> Soap client
> tooling.
>
> Whether a program can 'understand' the HTML it might retrieve from a
> Soap WSDL described web site doesn't matter. The ability to use web
> service tooling to do the retrieval is what is important.
>
> Many developers find the RPC view of a service a useful
> abstraction. If
> a web site wishes to provide a Soap RPC description of itself
> to cater
> to these developers, web services should support this.
>
> It should be possible to treat the Amazon XML over HTTP service as a
> first class web service, i.e. as a first class Soap service. As
> currently defined, the Amazon service that uses the Soap
> envelope on the
> wire does so to leverage web service tooling. In the future, web
> services should be able to pick from a spectrum of Soap bindings that
> include 'raw' HTTP as well as Soap over HTTP and other protocols.
>
> Web services should support a web service resource model that
> provides a
> basic level of a priori communication for applications that
> communicate
> at the Soap message level. This already exists and is being
> refined with
> idempotent request semantics. This will lead to some web service
> endpoints that cater to a priori access by providing simpler, more
> generic Soap messages (while some may cater to message level access -
> all will provide it). Their Soap WSDL description will provide basic
> message level access information and may provide additional
> RPC binding
> info so they can be easily accessed by clients from both the RPC and
> messaging API layers.
>
> Others have already suggested things along these lines. I
> would like to
> add my vote for a web service architecture that embraces REST and the
> existing web while extending the web with Soap.
>
> -- Mark
>
>
>
>
>
>
>
>

Received on Wednesday, 31 July 2002 14:17:30 UTC