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 03:04:17 UTC